offer an alternative to v-model to tag validatable Nodes

[Mikilll94]

Is your feature request related to a problem? Please describe.
In VeeValidate docs, it is clearly stated that if you are using ValidationProvider, the fields being validated must have a v-model directive. Unfortunately, this causes problems when using VeeValidate with Vuetify.

Here is the problem from Vuetify Github:

vuetifyjs/vuetify#6201

In short, Vuetify has a serious problem when dealing with large forms. When there are a lot v-text-fields with v-model the performance is really bad. When user types something in the input, there is a noticeable lag, which gets bigger when a form is growing.

The current workaround to that problem is to not use v-model and instead use :value and @change event on input like this:

<v-text-field
    :value="foo.bar"
    @change="v => foo.bar = v"
></v-text-field>

But ValidationProvider in VeeValidate requires v-model, so this not firing validation in VeeValidate.

Describe the solution you'd like
It would be awesome if VeeValidate worked with just events. v-model should not be required.

Additional context
VeeValidate 2.0 worked really well without v-model. However in VeeValidate 3.0 v-model is required and this makes it really hard when using it with Vuetify.

[logaretm]

Unfortunately, that is very hard to achieve. Consider this example:

<ValidationProvider>
  <TextSearch @change="updateValue" />
  <CategorySelector @change="limitScope" />
</ValidationProvider>

Now from the provider's perspective, both are just VNodes. Nothing is special between those nodes, the v-model help tag with the input we use to validate. And it also allows the provider to track the value correctly.

I will think of something, like an attribute that can be used aside from the v-model

<ValidationProvider>
  <TextSearch @change="updateValue" validateThis />
  <CategorySelector @change="limitScope" />
</ValidationProvider>

Feel free to suggest

[Mikilll94]

@logaretm
Hey, this idea with attribute to tag validatable inputs would be awesome. I have also found another use case when you cannot use v-model -> Vuex store. When an input is bound to the Vuex state field you cannot just use v-model but you have to commit a mutation in an event.

This attribute can be named, i.e. vvalidate. This name is simple, it is related to library name and also there is a low probability of collision with user-defined props or attributes.

[logaretm]

For vuex usually, you could use setters with computed properties to avoid this problem. But I do find introducing an alternative a good idea.

[trevorgehman]

This would be helpful in my case, where I have complex form component that is managing multiple inputs:

<ValidationProvider
   ref="provider"
   v-slot="{ invalid, validated }"
   rules="required|min_value:1"
>
  <!-- We need to use 'v-model' here to trigger validation. -->
  <SearchListsSubscribers
       v-model="selectedListCount"
       :lists.sync="lists"
       :subscribers.sync="subscribers"
       placeholder="Select list(s)"
       :has-error="validated && invalid"
   />
</ValidationProvider>

As you can see right now I have to create a computed property and use v-model. The only reason I'm doing that is so the ValidationProvider knows what data to validate.

The uniqueness of this situation is that I'm validating something that isn't directly tied to any single input.

Perhaps, it would be nice to have a prop on the ValidationProvider that I can just tell it what data to watch and perform validation on. Then I can just pass the computed property directly to the ValidationProvider and I wouldn't need v-model. (I believe in this case it wouldn't need to listen to input/blur/change events.)

[logaretm]

The Provider does not only need the node, but also its current value. Knowing the node will allow it to add all listeners needed to get the flags going and value syncing as well.

And knowing the value it will determine when to validate, having a custom property to tag the node isn't enough, such property needs to also carry the value.

Thanks to #2355 the provider should detect nodes with value prop in them on both native inputs and components, it will also play nicely with components having different props than value that has a model config on them. This can be still buggy and I patched some issues related to it recently, would be appreciated if we could get feedback on this improvement.

[mofman]

I'm having a similar problem, I want to prepopulate my form with existing data using the input value attrribute. But by adding v-model to the field means whatever is in the vue data overwrites the default value on pageload. The other work arround I've seen removes v-model and validates onInput - this is not ideal either as the form is invalid unless the user changes the fields.

<validation-provider rules="required" v-slot="{ errors }">
    <label :class="{ 'error' : errors[0] }">First Name
        <input type="text" name="v-model="firstName"" v-model="firstName" placeholder="" value="Joe Bloggs" >
        <small>{: errors[0] :}</small>
    </label>
</validation-provider>