Not sure how to properly approach defineModel with objects

[GabrielHangor]

Hello.

I've been experimenting with defineModel quite a bit lately and find it super neat and handy, however, not sure how to properly use it if we're dealing with objects instead of primitives.

Example: https://play.vuejs.org/#eNqFUlFPwjAQ/itNX9AEt4g+zUGiBqMmilEf+zK2A4pdW9sO0WX/3esGOETkqe333V2/u/tKeql1sCiARjS2qeHaEQuu0EQkctpn1FlGB0zyXCvjSEkMTEhFJkblpINpnQ11o9S1wqsE6VZ8ELZB/0vngkkmUyUtxihF+r7eUenvETntknFiItLz51eEn23D+G91jAXisBGKsvDhINcicYAvQuItFYuTXGUgsAssxCgJMSYOWwm0i/2hmgmfBnOrJA6h9GUYTbEIF2BG2nFUyyjK8YznEiHUx32NOVNAd42nM0jf/sDndukxRp8MWDALYHTDucRMwTX08OURlnjfkKi+EBj9D/kMVonCa2zCrgqZoexWXK32rt4Rl9NXO1w6kHbdlBfqI6s6nlHckZ/fvtZ/5J4F53UekxVO8feeD7ipMUC9HLRABhMu4cG/0AoG3gtuIFsNkbhPDREZjeeQusP751IX7cXXZ9CsH8NSmCmRgdmyxN40tN1OWoP5tDpxdjq4BZxw43isGYcINVRvUJarJqsK8d6O/apvuZsr/w==

So, update:modelValue not emitted from the child and the nested properties get directly mutated without any error. I expected the event to be emitted and the reference to foo in parent to be updated like when dealing with primitives but seems that's not the case for objects and arrays. How do you guys approach this?

I can even do smth like this and it will work which looks wrong to me:
https://play.vuejs.org/#eNqFUk2P0zAQ/SuWLwWpm2gLp5CtBGgRIMEi4OhLNpm2Lq5t/FEKUf47z0632+6ncoj93sz4zczr+Vtri20kXvHat07awDyFaJlq9PJC8OAFnwstN9a4wHrmaMEGtnBmwyZImxyoD8a8Nzhq0mHPF+UxmF6ZvBE6fa3RHlHGsItU8UWfzhU7n7LrxlVslv7/Kjx3CuPl4aXQdTkqhS5cAm2sagLhxlh9IqPamI7U2bZRkdALignOSgTW5VEWn6JLKFrIZbH2RmMUfaoleItKUpG7skFCseCQlJjENUqZP58zFlyk6Q3erqj99QC+9ruECf7NkSe3JcEPXGjcksJIX/74SjucDyR6iArRT5DfyRsVk8Yx7F3UHWQfxWW1n/KmpF7+9Je7QNrfNJWEpsghxwuOTaUhPtb6rdxXxeucJ/SAKd7d9jOeGk2QVwQbdLSQmr6kG+zg6HeUjrr9EFn4a6liV9dragM8ABs9ZQKpbQxse5Zr48H8L8b1I6yllVEduRNLPJoG691LG7GUlhNX5/OPhAmPvkfNugQ0UrN53++bHAbgs3v2G/4DBT0ubw==

[GabrielHangor]

Up

[kesoji]

I have the same problem (I don't have an ideal solution but I can emit events..).

Minimum Reproducible Code

Just like you, I want to define an Object type model with defineModel, but using defineModel like this:

export type Model = {
  a: string;
  b: string;
}

<script setup lang="ts">
import GrandChild from "./GrandChild.vue";
import type { Model } from "./type"

const model = defineModel<Model>()
</script>

<template>
  <div>
    <h3>ChildIdeal Component</h3>
    a: <GrandChild v-model="model.a" /><br />
    b: <GrandChild v-model="model.b" />
  </div>
</template>

(GrandChild is a simple wrapper for input. See the link above.)

GrandChild's v-model does NOT emit Child's update:modelValue so it means the object(=prop) is mutated.

In Vue devtools, there is only one emit which is from GrandChild.

So, I had to write like this:

<script setup lang="ts">
import GrandChild from "./GrandChild.vue";
import type { Model } from "./type"

const model = defineModel<Model>()

const onUpdateA = (a: string) => {
  model.value = {...model.value, a}
}
const onUpdateB = (b: string) => {
  model.value = {...model.value, b}
}
</script>

<template>
  <div>
    <h3>ChildActual Component</h3>
    a: <GrandChild :model-value="model.a" @update:model-value="onUpdateA" /><br />
    b: <GrandChild :model-value="model.b" @update:model-value="onUpdateB" />
  </div>
</template>

In Vue devtools, there are two emits which are from Child and GrandChild.

Declaring and using onUpdate function and binding model-value / @update:model-value is a tricky and reluctant solution...

We need a more simple and clear solution.

[HassanDomeDenea]

About this workaround, regardless of many code lines needed, does creating a new object and new reference each mutate influence performance or memory ?

[kesoji]

I don't have a detailed answer for it, but it should have slight impacts on performance and memory, especially in cases where the object is very large.

However, since {...obj} does not deep copy the whole object, unlike lodash.cloneDeep or structuredClone, its impact would be small.

[xxRockOnxx]

makes you think if you should have been using shallowRef if you're going to do it like this.

as for the updates, immer could be useful.

Just be wary of the "auto-freeze" thing it does which caught me off-guard as mentioned here: https://github.com/orgs/vuejs/discussions/12926

[michaelcozzolino]

check https://github.com/orgs/vuejs/discussions/10538#discussioncomment-12343316

[Pentadome]

Is mutating the prop value not considered bad practice anymore?
Or does defineModel not create a defensive copy for objects and we need to do it ourselves?

If the latter, I think a lot of buggy code will be written. I assumed that, internally, defineModel would call an "update:modelValue" event, with an updated copy, whenever we change a property value . I think a lot of other people assume the same.

Maybe defineModel should return ModelRef<DeepReadonly<T> > instead, to force us to create a new object, but this would be a breaking change.

[Gregoor]

This was exactly my assumption and I was wowed by the fact that it doesn't hold (wowed enough that it took me hours to find this being the cause of an issue)

[jaypeerj]

funnily enough, I've also been exploring this subject of late, and yes that is bad practice. RedBlobGames on my recent reddit gives a demo of why it is practically bad. I couldn't speak to whether prop mutation is inefficient or leaky (though I would suspect either or both might be the case)

think the main reason is that it changes the interface in a subtle way that's not apparent in the interface.

Here's a scenario based on a real-world problem I had ... Next year we want to change the parent point representation to be polar, with r: and angle: instead of x: and y:.

So we change the parent, and use <ChildComponent :location="polarToCartesian(point)" @update:location="point = cartesianToPolar($event)">. Maybe we use computed() with a setter to encapsulate this pair of conversions.

Under normal Vue conventions where children do not modify props, this change should work fine.

However, if the child mutates props directly, the code will break, because it's modifying the temporary value instead of the actual location. It's not something that's apparent in the interface, which only says that the v-model is a point with x: y:. And the bug may not be noticed right away, depending on how often that value is modified.

full discussion here;

https://www.reddit.com/r/vuejs/comments/1ftnali/vmodel_object_boilerplate_is_excessive/

[BenJackGill]

I would also like to use defineModel with objects. And I just leant about the problem of mutating object properties.

To avoid these pitfalls should I do something like this?

Not saying this is the solution, just wondering if this would avoid the problem until we have something better.

Here is the live example.

And here is the code from that example:

<template>
  Full Name Input in Child: <input v-model="localForm.name.fullName" />
</template>

<script setup lang="ts">
import { reactive, watch } from "vue";

// Making a form object with nested properties
interface ContactForm {
  name: {
    fullName: string
  }
}

// Creating the parnet/child component v-model sync using defineModel
const contactForm = defineModel<ContactForm>({
  required: true,
});

// Making a copy of contactForm to avoid mutating it's properties
const localForm = reactive<ContactForm>({ ...contactForm.value });

// Watch for changes in localForm and update the contactForm to keep it in sync with parent
watch(
  () => localForm,
  () => {
    contactForm.value = { ...localForm };
  },
  { deep: true },
);
</script>

[max-sistemich-kisters]

This won't solve the problem unfortunately, because localForm is just a shallow copy of the prop. Mutating anything at a single level of depth is fine, but in your example, you mutate localForm.name.fullName which will implicitly mutates the prop because localForm.name === contactForm.name.

You can solve that problem by copying with structuredClone(toRaw(obj)) instead of the spread operator.

[1652325]

Up, having the same issue

[atakchidi]

I caught this myself when tried to use shallowRef in parent. Vue documentation should be updated I was absolutely certain that define model creates a reactive copy of the passed prop. So that when I did modelValue.someField = value it would emit the new copy of the object not perform the actual direct mutation.

[jaypeerj]

I have discussed this issue on a stack overflow. The best suggestion I can make at this point is to use the similar but more feature rich vueuse function useVModel

I show a strategy over here:

https://stackoverflow.com/questions/79042840/vue-v-model-with-objects#answer-79047600

in brief:

const emit = defineEmits(['update:foo'])
const foo = useVModel(props, 'foo', emit, { deep: true, passive: true })

this emits correctly when changing deep properties of an object/array. it uses watchers under the hood so take that into consideration.

[stokedout]

It's a real shame there's no out of the box support for this, I ended up doing this
https://stackoverflow.com/a/79051046/978264

The tab-ing between elements is still glitchy but it's working even if I shouldn't modify props.

[paul-geisler]

(I landed here because of the same question.) Reading your example was like "wtf i'm doing exactly the same, line by line" ... But wouldn't it be easier instead of @blur using watchEffect? It would react to the changes of the input fields or am i wrong?

[Vasile-Peste]

I made a proposal for supporting it out of the box (with a solution which you can copy-paste): vuejs/rfcs#725

[Pentadome]

Is there any progress to use defineModel with objects out of the box?

[GabrielHangor]

No. We have 2 options: mutating nested properties of props directly or updating reference to the defineModel's model by shallow copying the original model and reassigning it.

I prefer the 1st option since it is cheaper and less boilerplate'y though against vue principals of not mutating props.

[michaelcozzolino]

In some cases i noticed that when i'm using deep nested components (3-4 layers), i lose reactivity by using the 1st option.
I made a proposal to have a v-deep-model directive. you an check it out here
vuejs/rfcs#751