Replies: 1 comment
-
Update: Is it a bad idéa to bypass handleSubmit in my case? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We have some special needs around our forms and have built a surrounding framwork to handle this. But one area is quite entangled with RHF's internal handling, this area is field errors.
A simplified description is that we need both "errors" and "warnings". They should be presented about the same to the user, but warnings should not prohobit submitting the form.
Sometimes a form needs to be used in a more relaxed way and always be able to submit, even if there are errors.
Example, two use-cases for the same form:
A form includes field "Name" which is
required
, i.e. RHF won't submit the form with an empty name.This is the correct process when the form is saved to "final version".
In our setup a form can also be saved as "Work in progress", i.e. we don't care if the form has errors, but we want to save all input values so the user can continue later, maybe even on another device. In this case we want to show "Name is required" as a warning, but we still need to submit the form.
Example, error vs warning:
A form includes field "Email address".
We have an api validation for email addresses, which can lead to either an error or a warning.
Error example: "This is not a valid email address"
Warning example: "This email is probably a spam address, avoid using it". (information from Zerobounce)
As RHF does not have a concept of warnings, we collect and handle warnings ourselves. If our custom validation should lead to an error we can use setError to tell RHF about the problem.
We cannot combine setError with native RHF rules, since these will clash and a passing RHF rule will clear errors. Hence all validation is taken care of outside of RHF.
To the point:
If RHF had a concept of "soft errors" we wouldn't need all the code outside of RHF.
Do we have really special needs, or are there other users who recognize this? To me it would be great to have both "warning" and "error" in RHF.
Another solution, which would solve half of my problem, would be if I could force-submit, even if there are errors.
I wonder if I might have missed some features that would help me out. Maybe RHF has support for "warnings", and I missed it?
Beta Was this translation helpful? Give feedback.
All reactions