I know there are a lot of similar questions, but I haven't found exactly my case.
Using vanilla JS there is an input control in which a user types something. A date as an example (but could be a phone number or anything else with a fixed format). The input data is validated using element's change event. So when a user finishes (by pressing enter or leaving the control, or submitting, etc.) a validation occurs and if something is wrong an error message is shown.
For a good UX the validation error is cleared once a user starts typing again (i.e. tries to edit the error). This is needed so the user is not confused that data is 'invalid' while he types it because he hasn't finished yet. And when he does finish typing, data is revalidated again. We are not doing real-time validation since it looks confusing ("am I typing already invalid data??").
For example, typing unfinished date like 12.12 (without a year) will result in validation error. And when a user starts typing again, the error is cleared until user is finished.
Now consider a case:
- user types
12.12; - presses
enter; - validation starts and results in an error;
- users clears input and types
12.12again; - presses
enter; - no validation occurs, since
inputelement sees no changes in it's value, hence nochangeevent.
So the question is, how to make input element believe that data is actually changed so the event is fired again when user finishes editing?
Not sure if emulating change event is a good idea (e.g. by dispatching it manually in blur or keypress=enter or anything similar).
I'm looking for something like an 'optimization' flag for input that when disabled will force it to dispatch change event regardless of actually changed value. Or something like invalidateElementValue that could be called inside element's input event.
From some of the OP's and my above comments ...
As I proposed/stated, validation happens at either (form-)data
submitor with everyinput-event or even at both event types. A good user experience comes with the kind and manner of how one interferes with a user's expectations. Thus, in order to provide the correct information, when hopefully needed, in the most supportive and least annoying way, one has to come up with some complex event- and data-handling. But this does not change anything about the suggested event-types.Note
The beneath posted code is not a suggestion of how the OP's problem has to be solved and validation needs to be done. It is just meant to be a demonstrator in order to show the complexity level needed when it comes to gathering the correct data upon which all UX decisions are going to be made.