Rethinking the "per-event" validation approach

[juliendelort]

Currently, it is possible to define different validation rules in different events (onChange, onBlur, onSubmitAsync etc...). If onChange does some validation, that validation is only run when the onChange callback is triggered (at each keystroke). So if the user submits the form without touching it, the validation is not done (onSubmitAsync needs to be implemented in thiscase).

I'm seeing potential issues with this approach (separating out validation per event - onChange vs onBlur vs onMount etc...). I don't know if there is a use case where users would want to do different validations in onChange and onBlur and onSubmitAsync for example. From my experience, a field is either valid or invalid at a given time, regardless of when the validation is done, and users may often end up reusing the same validation rules in onChange and onSubmitAsync or in onBlur and onSubmitAsync for example.

Imo, it could make things simpler if we decoupled the validation rules (what makes a field valid) from when the validation should be done.

Another challenge created by this approach is that errors are cleared by the same event that raised them. For example if onBlur returns a validation error, that error will only be cleared the next time the field is blurred. In some use cases, users could want to do the initial validation on blur but remove the errors as the user is typing to fix them. Here is an example: (type 2 characters in the first name field then focus the other field: "First name must be at least 3 characters" is shown. It could be good to be able to remove the error as soon as the user types the third character).

I believe this is also what is causing this issue about validating untouched forms.

[tannerlinsley]

I like this idea. It’s safe to assume that there is a cascading matrix configuration for this. Eg, when you do an onchange validation, you also want it to automatically do an on submit as well. The sync/async distinction is still important. We should figure this out quickly. Tanner Linsley

…

On Oct 26, 2023 at 7:29 AM -0700, Julien Delort ***@***.***>, wrote: Currently, it is possible to define different validation rules in different events (onChange, onBlur, onSubmitAsync etc...). If onChange does some validation, that validation is only run when the onChange callback is triggered (at each keystroke). So if the user submits the form without touching it, the validation is not done (onSubmitAsync needs to be implemented in thiscase). I'm seeing potential issues with this approach (separating out validation per event - onChange vs onBlur vs onMount etc...). I don't know if there is a use case where users would want to do different validations in onChange and onBlur and onSubmitAsync for example. From my experience, a field is either valid or invalid at a given time, regardless of when the validation is done, and users may often end up reusing the same validation rules in onChange and onSubmitAsync or in onBlur and onSubmitAsync for example. Imo, it could make things simpler if we decoupled the validation rules (what makes a field valid) from when the validation should be done. Another challenge created by this approach is that errors are cleared by the same event that raised them. For example if onBlur returns a validation error, that error will only be cleared the next time the field is blurred. In some use cases, users could want to do the initial validation on blur but remove the errors as the user is typing to fix them. Here is an example: (type 2 characters in the first name field then focus the other field: "First name must be at least 3 characters" is shown. It could be good to be able to remove the error as soon as the user types the third character). I believe this is also what is causing this issue about validating untouched forms. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[juliendelort]

Thanks Tanner!

I have a suggestion regarding the validation API: at the field level we could replace the onBlur, onBlurAsync, onChange, onChangeAsync, onSubmitAsync callbacks with the following:

• validate and validateAsync: Same signature as onBlur/onChange and onBlurAsync/onChangeAsync respectively: they would receive the field value and return the error if any. This would be the centralized place to specify how to validate a field.
• validateOn: 'change' | 'blur' : Controls when the validation is triggered. When the validation is triggered, then validate and/or validateAsync is called. We could also add "mount" as a possible value but not sure when errors would be cleared.
• revalidateOnChange: boolean: When the field is in error, this would override the validateOn field and trigger the validation at each keystroke (the name could even be more obvious, something like "revalidateOnKeystroke"). Once the error disappears, we revert back to what's specified in validateOn. For example, we could have a field initially validated on blur, but once the field is in error we'd want to revalidate at each keystroke so that the user sees the error disappear as they type.

We could also expose similar options at the form level which would apply to all fields (unless some fields override it). The only difference would be validate and validateAsync at the form level would receive the values of all the fields and return a mapping {fieldName: error}.

Any thoughts?

[crutchcorn]

I strongly dislike this API and is something we'd (Tanner and I) discussed when I first got involved in this project. In fact, Tanner had things established this way and through a live-pairing session we exposed when it was a problem and refactored to what we have today.

The onChange, onBlur, etc allow for much more substantially flexible validation when stakeholders require it. We've had this happen directly at my organization and had to eject out of React Hook Forms for this very reason. Having per-field validation customizability is a huge win for TanStack Form, and isn't a project I'd want to use without.

[crutchcorn]

While I've responded to the suggested API change, allow me to propose my own:

onChange and onBlur should run onSubmit, just as it does on HouseForm. The idea here isn't that onChange should only run onChange, but more that "it should run onChange and prevent a submit if it's also invalid"

[tannerlinsley]

Yes. This is pretty much what I was getting at. Also @crutchcorn, we discussed scoping the validators so as to not interfere with potential semantics around a generic field onChange functionality (which may or may not also be something we add in the future)

[crutchcorn]

Yup yup! Here are the two GH issues we'll use to track this:

#490
#491

[juliendelort]

No worries, thanks for the feedback!