API to support: reward early, punish late UX

[jods4]

Is your feature request related to a problem? Please describe.
The best UX when it comes to validation is a concept sometimes referred to as "reward early, punish late".

In practice, it means that:

• if a value is invalid, as soon as the user fixes the input it should be green again (reward early).
• if a value is valid, it shouldn't become red until the user finishes its input -- typically at blur or change events (punish late).

A sample interaction, would be:

• Say field A must be at least 4 characters, and is currently "1235" (valid).
• User wants to fix this to 1234, so it removes the "5" -> the input should not flash red yet!
• User types the "4"
• Value is committed (e.g. blur event), 1234 is valid, field stays green.

On the other hand, if field was "123" and red, as soon as the user types "4" the error should go away.

I have built such UX on top of vuelidate, but it could easily have built-in support, with just two small additions that I'm proposing below.

Describe the solution you'd like
Today $error indicates if the error should be displayed in UI, and is based on $invalid + $touch() events (a non-dirty value is not displayed in red).

I propose to optionally change $error behavior to match the UX described above.
This would be opted-in by users using with a new option { useCommit: true }.

There would be a single new API $commit() to support this feature.

How it would work:

• If option { useCommit: true } is not used -> everything works as today. $commit() is a synonym for $touch().

Otherwise:

• When touched, if $invalid is false then update $error = false, like today.
• When touched, if $invalid becomes true -> do nothing!
• When $commit() is invoked, call $touch(), then set $error = $invalid.

Top level API $validate() should call $commit() on each field instead of $touch().

And that's it.

Describe alternatives you've considered
You can build this on top of the Vuelidate object, but it's a bit hacky / more complicated.

[dobromir-hristov]

Hey there, interesting concept. I have a few questions.

1. You are proposing we dont change the way validators get invoked, rather the way we construct the $error state?
2. You want the validator to show green immediately upon fixing an invalid field, but show red ONLY upon invoking a helper?
3. Commit is probably not the word I would use.

I suppose we would need yet another state, that we would track.

So if

1. If $invalid === false and $committed === false, then $error is false.
2. if $invalid === true but $committed === false, then $error is false.
3. If $invalid === true and $committed === true, then $error is true.
4. Upon changing $model, or if using $autoDirty the state, $committed goes back to false.

I suppose this is kind of similar to doing the thing below, with the exception that it wont reward "early".

<input v-model="name" @blur="v.name.$touch()" @focus="v.name.$reset()">

[jods4]

Just so you know, in the end we replaced Vuelidate with our own validation code that includes this built-in.

To answer your questions:

1. Yes. Since $error is meant to be what the UI binds to, the proposal here is to have an option to slightly change the timing of the feedback, in other words to change the behavior $error.
2. The gist of it is that the field should be green as soon as the user fixes a validation error (e.g. starts typing in an empty required box, typically @input, basically $touch).
   It should be red only when the user is done (typically @change). For example, if I'm typing a phone number, the box shouldn't be red while I'm typing the digits because I'm not finished yet.
3. Naming is hard! 😄

I think of commit more as an action than a state. You can create a $committed flag and reset it anytime $touch is called, but you can also do without it.
Basically the 3 (actually 2) steps is listed above should work well enough:

1. When touched, if $invalid is false then update $error = false, like today.
2. (When touched, if $invalid becomes true -> do nothing!)
3. When $commit() is invoked, call $touch(), then set $error = $invalid.

See it in action!
Here there's a validator on the time format.
In particular, notice how when I'm going from 06:30 to 06:25 there's no flashes of red when the box contains 06:, an invalid input!

[darrinmn9]

I would also love this feature. I'm still on vuelidate 0.7, and had to build alot of additional logic/state on top of the vuelidate object to satisfy my design teams ask for "reward early, punish late", and i would love this built in!

I'm really not proud of my own implementation on top of vuelidate to get this UX (not vuelidate's fault, just sometimes my own code/abstractions scare me), this would be a huge win to have built in. As mentioned in the original issue comment,

Describe alternatives you've considered
You can build this on top of the Vuelidate object, but it's a bit hacky / more complicated.

^ I couldn't agree more

[JohnCampionJr]

Any way I could help on this? Would love this feature, but it seems a bit major to tackle.

[dobromir-hristov]

Anyone want to try out the #951 PR before I merge it?

[JohnCampionJr]

Will do but it won't be until Sunday or Monday.

[edwardscull]

Apologies for commenting on a closed issue and also if there is another issue referencing my issue at hand. Which is as follows:

Only validate on form submission

I am the author of a public sector design system. The issue I am having touches on higher level UX validation philosophy. When do you show and hide red text/error state to the user?

My use case, which backed by the research done on the UK GOV Design System (which is what my design system is based off) explains

Do not validate when the user moves away from a field. Wait until they try to move to the next part of the service - usually > by clicking the ‘continue’ or ‘submit’ button at the bottom of the page.

Generally speaking, avoid validating the information in a field before the user has finished entering it. This sort of validation > can cause problems - especially for users who type more slowly.

From my limited interaction with Vuelidate, from hunting through the API and documentation, that this behaviour appears to not be supported. My guess is that this is by design and speaks to a more UX decision and not a technical one.

However, I do think there is a valid case for it, as described in the article linked above.

I essentially want to prevent the behaviour of Vuelidate validating any fields on any HTML event e.g. blur. The $lazy option only gets partly there and allows me to call $v.value.validate() in my submit action. Any user interaction after this goes back to validating on an event change. I want to keep the entire form red and in error (for those that are invalid of course) UNTIL the user has clicked the submit action once again.

• Is there a way to do this that I am missing?
• Is this something that has been considered?

The library is great to use more generally speaking and does give me the tools I need to model forms across a design system consistently, plus many helpful validators out of the box. Therefore, I would like to try and solve this without rethinking my entire approach.

A potential solution is to have a completely separate flag/state that gets updated every time a submit action is called. Then allowing to do a further check when showing error messagese e.g. <p v-if="$v.input.$errors[0].$message && myCustomBooleanFlag"/>{{ customComputedErrorMessage }}</p>. Update: This solution also does not work and the field remains to be flagged as valid once an input etc event occurs.