Conditionally Require Fields

[ChadLefort]

Hello, just started using this library, and I have to say it’s great and thank you for creating it! I’ve run into one small issue that I can’t figure out after looking through the docs.
​
I need to conditionally require a field input, but this field input needs to always be shown on screen. So for example, I have a select with yes/no options and another textarea field for a comment. If I select no then the comment field becomes required.
​
The only option I could sort of find was to duplicate the object and include the validate and isRequired properties on one object and exclude them on the other. Then have the conditional property toggle the visibility of fields.
​
However, this does throw a key warning. For my use case I need both name properties to be the same. The name property will be tied to an id that the backend will save the answer to.
​
Is there an option that I’m missing to conditionally include properties such as
​

isRequired: true,
validate: [
 {
   type: ‘required’
 }
],

​
on just one object? I can currently only see that I can set a value/visibility.
​
Here is a codesandbox with the schema that describes my current issue:
https://codesandbox.io/s/data-driven-forms-conditional-required-s9eme?file=/src/App.js

[rvsia]

Hello, thank you for your kind words! We really appreciate it! 👍

You can get rid of the key warning by setting a key property in the schema:

        {
          component: componentTypes.TEXTAREA,
          name: "comment",
          label: "Comment",
          key: 'second', // some key
          isRequired: false,
          condition: {
            when: "continued-use",
            is: "yes"
          }
        }

And I agree, this would be the way I would implement this right now.

However, we could use this case to improve the library. There are two options what to do (and we could do both):

1. Create a new conditional action

{
   when: 'field',
   is: 'true',
   then: { setProps: { ... } },
   else: { setProps: { ... } }
}

2. Move resolveProps execution before the useField is used.

react-forms/packages/react-form-renderer/src/files/use-field-api.js

Line 170 in 2c5978d

...(resolveProps ? resolveProps(cleanProps, fieldProps, formOptions) : {}),

this would neeed to be tranformed into

    ...(resolveProps ? resolveProps(cleanProps, {input: { value: formOptions.values[name] ,name}, meta: formOptions.getFieldState(name)}, formOptions) : {}), // methods' names are not correct, just for the example

Then, it would allow to modify validate property from the schema.

---

Do you want to make us a PR for this? I can take a look next week or maybe @Hyperkid123 will find some time sooner.

[Hyperkid123]

I might take a look tommorow. My schedule is a bit bussy right now.

[Hyperkid123]

@ChadLefort @rvsia So I was thinking about it a bit and we should go with option 1. Enhancing the condition definition with a setProps action usable in more scenarios. I should have a PR open later today or tomorrow.

Set props from condition results will obviously have higher priority and override anything from schema props.

[Hyperkid123]

I have a solution, but there is an issue with final form not properly registering to validate prop change. There is a hack around it though.

[Hyperkid123]

Well I, was mistaken. The hack around it does not work. 🤔 This might not be solvable until we switch to our new state manager.

@ChadLefort It works ok for normal component props, like the required prop but the final from validate is busted. I might have another solution that will not require any additional features. Here is a codesandbox with working implementation using custom validation, resolveProps and subscription. https://codesandbox.io/s/data-driven-forms-example-forked-izlrt?file=/src/App.js

So there is a handful of options.

1. Implement the setProps. This will be buggy since you can't use it properly for changing validation prop which is the main purpose of this issue. At least not until we finish our state manager and switch over to it.
2. Use the solution from the code sandbox example. Be aware that you must set the subscription to values which might hurt performance in complex forms
3. Use the current implementation for the moment.

We might try and create an issue on final form repository for now. Here is another codesandbox example which shows the broken validation: https://codesandbox.io/s/confident-cohen-6z6dc?file=/index.js. But I am not sure how if that ever gets fixed. And for us its another reason why we want to create our own manager so we can fix issues like this ASAP.

[rvsia]

@Hyperkid123 there is an official instruction how to solve the validate change: https://final-form.org/docs/react-final-form/types/FieldProps#validate

[Hyperkid123]

@rvsia yeah I've seen that. Here is the problem though. What prop do we change? We can't just willy nilly change props from the schema. We could come up with some arbitrary prop name, but we can then override some prop required by the component. Unless we give it some totally unreasonable name. Key is the first thing that came to my mind.

Also what about components that have some effects on the mount etc? Like selects with load options. It will break the lifecycle since we will destroy the component instance.

Maybe just wrapping it into a fragment could be reasonable:thinking:. it will be less buggy but still opens up a way to bugs. I might do it though and put some fat warning to the docs that it may cause lifecycle issues.

Edit: @rvsia
Also that does not work with useField hook. Check this: https://codesandbox.io/s/changing-field-level-validators-forked-r3zr7?file=/src/index.js. The validation gets assigned then it's not supposed to be and vice versa once you start changing it.

[ChadLefort]

@Hyperkid123 Thanks for providing a solution! That sandbox you've linked seems to resolve my issue. I'm going go ahead and implement it into my project and see how it goes. I didn't even think about using a custom validator and passing a custom prop to the schema like that.

Yesterday I did spend a bit of time, and I got the setProps to conditionally include isRequired or really any prop you would include in that object, but I didn't get around to figuring out how I would conditionally do validate.

[Hyperkid123]

@ChadLefort yeah, I know it's not an ideal solution right now. Hopefully, we will be able to fix this and enable the setProps attribute in condition for all props without any bugs.

[skateman]

Maybe this helps ... I implemented a PoC of conditional validations here: ManageIQ/manageiq-ui-classic#7312