ValidationObserver should also expose fields in addition to errors.

[hannesaasamets]

Form validation progress was easy-to-achieve in Vee-Validate 2, since it exposed this.fields.

But in Vee-Validate 3, ValidationObserver only exposes errors. The problem is it does not reflect the invalidity of a required field while it has not been touched yet.

This makes it near impossible to observe the individual fields' validity without recollecting the state from each component manually, which should be the work of ValidationObserver.

ValidationObserver should also expose fields in addition to errors in order to achieve form validation progress as shown in the following gif:

[logaretm]

That's a good use-case. I think it should be trivial to implement such a feature, will check it out tonight.

[hannesaasamets]

So is it trivial on a closer look as well?

[logaretm]

Yea, but I'm thinking about its type, like a Record<string, boolean> or string[] and I didn't really get the time to tackle it yet.

[hannesaasamets]

What would be the benefits of the Boolean?

[logaretm]

I'm looking for this:

booleans

<ValidationObserver v-slot="{ fields }">
  <p v-if="fields.name">Please Correct the Field name</p> 
</ValidationValidation>

array of strings

<ValidationObserver v-slot="{ fields }">
  <p v-if="fields.length">Please correct the {{ fields[0] }} field</p> 
</ValidationValidation>

The array looks nicer in that exact case, but consider this one:

array of strings

<ValidationObserver v-slot="{ fields }">
  <p v-if="fields.includes('name')">Please Correct the Field name</p> 
</ValidationValidation>

Which is not useful if you need access to specific fields. Feel free to suggest more formats/types.

[ryleyb]

I actually have run into the case where all the VPs are in one area, but specific icons need to go in a different area to represent different errors. Thus, in my use-case, having a VO fields that looked like an Object with keys being the VP vid and the values being the VP's failedRules would be most helpful:

{
    _vid1: {
         required: 'msg',
         min_value:'other msg'
   }, 
  ... etc
}

[logaretm]

@ryleyb That sounds good but because observers can be nested, it makes it hard to make a predictable structure. Either nested observers should be removed (which I'm leaning towards) since there isn't a single use-case that justifies it so far.

[logaretm]

This is finally implemented here #2535

would love some comments before I can merge for 3.2

[DM2489]

@logaretm The feature would be very handy, and the implementation looks solid to me. I'd like to see this merged and 3.2 released 👍