Most form validation libraries will provide developers with options for revalidating a field that has already been validated at least once.
How It Works
Consider a situation where a developer has asked a form validation utility to validate fields onfocusout (the bubbling version of onblur) and to revalidate them oninput. Let's say that an email field is in the form and is required. If a user visits the field and then leaves it (focusout) without entering anything, then the field will be marked as invalid, and an error message like "Email is required" will be displayed.
The user realizes that they cannot ignore the field. So they return to it and start entering a value. Because this field was already validated at least once, the revalidation feature kicks in. In our case, revalidation occurs oninput; so as the user starts typing in a value, the error message gets updated. If the user enters "e", then the error message will immediately change to "Email is invalid" because the field was revalidated oninput. This error will continue to be displayed until the user provides a valid email address. Note that because revalidation is now happening oninput, the user will be able to see that their field is correct before they leave it (i.e., "blur" it). Note that validation will still occur onfocusout. However, this won't cause a noticeable difference anymore because the field will have been validated on its last input event before the field is blurred.
Sometime later, the user might choose to be silly and modify the email field to something invalid again. As they do so, the error messages will reemerge oninput. Remember: Because this field was already validated at least once, the revalidation feature is active. So even if the user makes the field valid, it will still be validated oninput from this point onwards.
Now let's say that the user has moved on to the confirm-email field. They've learned their lesson with the email field and don't have any interest in generating any error messages. They start to type the letter e; but because the field has not yet been validated (automatically or manually), no error message pops up. They perfectly supply a valid email with a value that matches what's seen in the other email field. So when they leave the confirm-email field, no error message pops up.
This means that the user was able to interact with the confirm-email field without ever seeing an error message for it. However, once the user leaves the field, it will be validated (because the focusout event will have triggered). Consequently, if the user returns to the field and makes it invalid, then they will see error messages for that field.
Difficulty of Implementation
Moderate
The effort certainly shouldn't be significant. But the effort isn't trivial either. (The effort might be "easy", if that were a value between "trivial" and "moderate".)
Usage
From the standpoint of a developer, the usage would be simple and would look something like the following:
const observer = new FormValidityObserver("focusout", { revalidateOn: "input" });
Other Notes
Obviously, whatever solution that we come up with should be performant. (At the very least, it should not harm performance.)
People could debate whether revalidation should kick in after a field is validated for the first time or after a field is marked as invalid for the first time. The former is probably more intuitive to users.
People could debate whether revalidation should be disabled after a field is made valid. My initial intuition is that it is less intuitive for revalidation to be disabled after a field is made valid. (For instance, someone may wonder why a field started to be validated oninput and then suddenly stopped being validated oninput.)
Browsers already seem to have some kind of "revalidation behavior". (At least, Chrome does.) When a form field's error message is reported by the browser, the browser will continue to show updated error messages oninput until the field becomes valid. Therefore, the revalidate feature for the FormValidityObserver is arguably an enhancement over what the browser already has.
We don't really need to support revalidating onsubmit. The validateFields method is already exposed to developers for use in their submission handlers. They can run validation there instead of relying on a configuration option.
If we provide a default value for revalidateOn, it should probably be either input or nothing. I'm leaning towards nothing, as that seems more intuitive. After all, revalidateOn may not even be necessary if validation is done onfocusout or oninput.
If possible, the revalidateOn property (or whatever we name it) should probably prevent developers from supplying redundant events. In other words, the following should be forbidden (at least by TypeScript):
const observer = new FormValidityObserver("input", { revalidateOn: "input" });
This would be wasteful and redundant. Therefore, it should be forbidden. (We won't go as far as throwing errors at runtime, though. That's also arguably a waste, though not a significant one.)
ITenthusiasm
commented
5 months ago
Motivation
Most form validation libraries will provide developers with options for revalidating a field that has already been validated at least once.
How It Works
Consider a situation where a developer has asked a form validation utility to validate fields
onfocusout(the bubbling version ofonblur) and to revalidate themoninput. Let's say that anemailfield is in the form and is required. If a user visits the field and then leaves it (focusout) without entering anything, then the field will be marked as invalid, and an error message like "Email is required" will be displayed.The user realizes that they cannot ignore the field. So they return to it and start entering a value. Because this field was already validated at least once, the
revalidationfeature kicks in. In our case, revalidation occursoninput; so as the user starts typing in a value, the error message gets updated. If the user enters"e", then the error message will immediately change to "Email is invalid" because the field was revalidatedoninput. This error will continue to be displayed until the user provides a valid email address. Note that because revalidation is now happeningoninput, the user will be able to see that their field is correct before they leave it (i.e., "blur" it). Note that validation will still occuronfocusout. However, this won't cause a noticeable difference anymore because the field will have been validated on its lastinputevent before the field isblurred.Sometime later, the user might choose to be silly and modify the
emailfield to something invalid again. As they do so, the error messages will reemergeoninput. Remember: Because this field was already validated at least once, the revalidation feature is active. So even if the user makes the field valid, it will still be validatedoninputfrom this point onwards.Now let's say that the user has moved on to the
confirm-emailfield. They've learned their lesson with theemailfield and don't have any interest in generating any error messages. They start to type the lettere; but because the field has not yet been validated (automatically or manually), no error message pops up. They perfectly supply a valid email with a value that matches what's seen in the otheremailfield. So when they leave theconfirm-emailfield, no error message pops up.This means that the user was able to interact with the
confirm-emailfield without ever seeing an error message for it. However, once the user leaves the field, it will be validated (because thefocusoutevent will have triggered). Consequently, if the user returns to the field and makes it invalid, then they will see error messages for that field.Difficulty of Implementation
Moderate
The effort certainly shouldn't be significant. But the effort isn't trivial either. (The effort might be "easy", if that were a value between "trivial" and "moderate".)
Usage
From the standpoint of a developer, the usage would be simple and would look something like the following:
Other Notes
revalidationshould kick in after a field is validated for the first time or after a field is marked as invalid for the first time. The former is probably more intuitive to users.revalidationshould be disabled after a field is made valid. My initial intuition is that it is less intuitive forrevalidationto be disabled after a field is made valid. (For instance, someone may wonder why a field started to be validatedoninputand then suddenly stopped being validatedoninput.)oninputuntil the field becomes valid. Therefore, therevalidatefeature for theFormValidityObserveris arguably an enhancement over what the browser already has.onsubmit. ThevalidateFieldsmethod is already exposed to developers for use in their submission handlers. They can run validation there instead of relying on a configuration option.revalidateOn, it should probably be eitherinputor nothing. I'm leaning towards nothing, as that seems more intuitive. After all,revalidateOnmay not even be necessary if validation is doneonfocusoutoroninput.revalidateOnproperty (or whatever we name it) should probably prevent developers from supplying redundant events. In other words, the following should be forbidden (at least by TypeScript):This would be wasteful and redundant. Therefore, it should be forbidden. (We won't go as far as throwing errors at runtime, though. That's also arguably a waste, though not a significant one.)