Revalidate when children changes

[simplecommerce]

Hi,

I was wondering if you guys had any better approach/suggestion.

I have a form with a Select component.
When I select an option, I render other fields that are required based on the selected option.

My issue, is when the new fields render and appear in the form and submitted is true, it will not re-execute the validation and won't include the new fields.

The only way I found to make this work was to add a useEffect in my children components and call validate() when they mount if submitted is true.

If you have any ideas or better approach let me know.

[radekmie]

Hi @simplecommerce. Technically, it shouldn't matter if a field is visible or not - the user completed it by successfully validating the data. In other words, the visibility of a field should not affect its validation.

What we do in our Form Builder is a schema that is aware of visibility, i.e., both the validation and rendering use the same logic. This makes this problem non-existent as if a field should not be visible, it is not validated and it gets validated if it is. The last part is that the conditions may include only one source of variables - the state of the form (i.e., values of other inputs).

What are the conditions you show/hide your fields on? If they rely only on the model, it should be pretty straightforward.

[radekmie]

When I select the type PAYMENT and the new field date is rendered, onValidate isn't re-executed [...]

But why? If it would, the problem is solved. You could have these "differentiator fields" (I like to call them "kinds") in the schema, and remove them when the form is submitted. You could even fit them into a $ or __switches__ field to make them "more separate" (for people, of course).

Other than that, I'd like to see the repo to play with it myself.

[simplecommerce]

When I select the type PAYMENT and the new field date is rendered, onValidate isn't re-executed [...]

But why? If it would, the problem is solved. You could have these "differentiator fields" (I like to call them "kinds") in the schema, and remove them when the form is submitted. You could even fit them into a $ or __switches__ field to make them "more separate" (for people, of course).

Other than that, I'd like to see the repo to play with it myself.

I wasn't able to create a working repo to reproduce the issue as of now, because I think my logic for dynamic field (JSON) is flawed.
So for now I am leaving this aside.

I did however encounter an issue with the same principle of revalidating when a children changes.
In order to dynamically require a field that isn't required in my schema, I am passing the required prop to the child in question.
In my custom bridge, in the getProps method, I am storing the field's required prop in a local variable in the class.

In my custom method which validates all required field based on schema, had it also look at the local variable in order to validate it, if it isn't required in the schema but might be required because of the prop.

My validaton method is called using onValidate

The goal of this scenario was to be able to force a field to be required based on a selection or input from another field.

My problem seems to be when the form is in a validating state.
It calls the onValidate before the children are re-rendered. In my case since the required prop changed in a child, it doesn't see it and only sees the previous value.

In order to fix this, I was forced to use useEffect in my child to listen for a change in the required prop and call validate().

Here is the repo I was working on but I tweaked for this specific scenario.

https://codesandbox.io/s/graphqlbridge-with-dynamic-field-json-scalar-is9nnr?file=/src/App.js

I know this isn't really an issue with your library, but I was wondering if you see any other way around this.

Thanks!

[radekmie]

Honestly, I've never thought of a case, where passing required as a prop to a field would mean this field is actually required in the validation. It's because the bridges (schemas) are stateless by default, and should not care about the UI at all - the data is the only thing that matters.

We did have a few times a similar case, and we solved it by making a function that created a new bridge based on some conditions. Then we memoized all of them and used them as usual.

To be honest, I don't have a solution now, but using this useEffect is not bad, I think. You could even have one useEffect, next to the place where the form is rendered, that could have both the previous and current model and do that in there. Alternatively, you could schedule a validation in onChangeModel.

[simplecommerce]

Honestly, I've never thought of a case, where passing required as a prop to a field would mean this field is actually required in the validation. It's because the bridges (schemas) are stateless by default, and should not care about the UI at all - the data is the only thing that matters.

We did have a few times a similar case, and we solved it by making a function that created a new bridge based on some conditions. Then we memoized all of them and used them as usual.

To be honest, I don't have a solution now, but using this useEffect is not bad, I think. You could even have one useEffect, next to the place where the form is rendered, that could have both the previous and current model and do that in there. Alternatively, you could schedule a validation in onChangeModel.

yeah I know my use case is very specific and I wasn't expecting any other solutions at this moment, but I appreciate your reply.
I will try and check if onChangeModel can work for my case also. Your function to create a new bridge, did it create a new one when a model value changed? Or did you generate every possible bridges based on possible values?

Thanks again!

[radekmie]

Your function to create a new bridge, did it create a new one when a model value changed? Or did you generate every possible bridges based on possible values?

It took a few flags from the model, like "x is bigger than 100" or "both z and y are present", and was run every time, but in a memoized function.