Vee Validate overriding component model value.

[cadriel]

What happened?

<template>
  <v-dialog
    :modelValue="modelValue"
    @update:model-value="emit('update:modelValue', $event)"
    max-width="300px"
  >
    <v-card>
      <pre>the model value: {{ modelValue }}</pre>
      <pre>some field: {{ value }}</pre>
    </v-card>
  </v-dialog>
</template>

<script setup lang="ts">
import { useField } from 'vee-validate'

export interface Props {
  modelValue: boolean
}

defineProps<Props>()
const emit = defineEmits<{
  (e: 'update:modelValue', value: boolean): void
}>()

const { value } = useField('someField')
</script>

Vue 3.3.4
Vuetify 3.2.5 (same result with 3.3)
Vee-Validate 4.9.4

Given the above component, the modelValue and someField are now tightly bound in that they both represent the same value when they should not. I.e., if you put a button that adjusts the value of value.value = false the model would incorrectly close.

I'm having trouble figuring out if this is something I'm doing, or if this is a Vee-Validate issue. But it sure seems strange that Vee-Validate would be overriding the model prop on the component in this way.

Reproduction steps

No response

Version

Vue.js 3.x and vee-validate 4.x

What browsers are you seeing the problem on?

• Firefox
• Chrome
• Safari
• Microsoft Edge

Relevant log output

No response

Demo link

NA

Code of Conduct

• I agree to follow this project's Code of Conduct

[cadriel]

Ok.. after much frustration, I found this;
https://vee-validate.logaretm.com/v4/guide/composition-api/validation/#usefield-model-events

Sure enough, setting syncVModel: false resolved the issue.

However - I think its worth discussing having this value default to false, because;
a) it took me a day to figure out WHY the library was overriding the modelValue on a component without explictly being told to and;
b) to find the documentation explaining the above.

[logaretm]

I think its worth discussing having this value default to false

I think yes, that would have been a better default. However, it is too late to turn it off now because people are probably using it.

The rationale then was that people struggled with syncing v-model on their inputs and wondering why didn't vee-validate do that automatically. Docs didn't adapt well to that especially since there was no alternatives for useField to create "models" of data which is now solved with defineInput/componentBinds.

I'm in the process of re-writing the composition API docs which will include a guide page dedicated to building form inputs with useField. I hope this resolves the issue or make it easier to figure out what useField does under the hood.

[cadriel]

I understand.

However, having recently moved a project to Vue 3 and the Composition API - I think leaving a library in this state is only going to cause further confusion for others - especially given the state of Vuelidate and its lack of maintainers.

A composable that forcefully overwrites the modelValue of a component seems particularly bad form - since there's no visible indication as to why its happening - nor any configuration user side to indicate this.

So - I implore you to re-consider - but understand this is your choice.

Thanks!

[cadriel]

Perhaps another option;

• In my case, if I had three useField values - all three were overridden by the model. This seems like a seperate bug?
• I also had a useForm above the useField's.

Would it make sense for the default to NOT apply if you have more than one useField, or a useForm defined? It seems like it shouldn't apply under those circumstances.

This way you could still keep your existing default whilst avoiding some of the impact of having it default to true.

[logaretm]

I though about it again and I I'm disabling it by default for v4.10, thanks for your suggestions and while they can work in some cases I think they will still not cover all the basis:

• We can detect useForm being used on the same component, no problem there.
• We could detect if there are other useField within the same component but the very first one won't be detecting that. so that's a situation where it fails.

So I decided to disable it, thanks for suggesting this and pushing it, I think it should've been opt-in from the start.

[joe-yates]

@logaretm this change has completely broken our application and took hours to investigate. This breaking change should have been done in the next MAJOR version, with accompanying migration guide!

Please refrain from making future breaking changes without a MAJOR version.