Is v-model counter-intuitive?

[Gregoor]

Hi!

I've just boiled a few hour bug chase down to this.

Now I'm wondering if other people have run into this confusion, namely that v-model setting a two-way binding means that whatever you pass in, will be mutated in-place.

Maybe it's my React background, but this seems mighty implicit for something that can cause such subtle bugs. In my case I had a deep object, where mutation happened in some leaf object, which would then also change the preset which it was originally a reference to.
My solution was to do a deep copy instead of reusing objects.

I would see value in more explicit documentation about it, but overall I also have to say that I find such an API obtuse

[s3xysteak]

v-model:foo="bar" is actually equal to :foo="bar" @update:foo="val => bar = val".
So it just pass the value to child component, and update himself when the child component updated. The desired result is that they can be deeply bound.

[Gregoor]

That part I did get from the docs. Looking at it again today, with new eyes, maybe it's just a matter of internalizing that transformation and having the automatic thought "v-model is going to mutate whatever I pass in". I suppose a decade of React and immutable-style UI programming has made my head thick for such an idea too sink.

Then again, where I do think there might be more objective danger here is in a detail that I omitted in the above example, that was present in my actual case:

In it I set part of the model's value to a reference to another object. This was then mutated somewhere deeper in the tree. Maybe it's my background, but I think that (tbf logical) consequence deserves a note of caution.

[Hiws]

Sounds like the information you're looking for is this.
When you consider that v-model is just a shorthand for a prop and event.

Though I agree that the newly added defineModel has made it less clear, that this is the case. Compared to before where one specifically would declare the prop and emit.

[s3xysteak]

In my opinion, passing by value might be more intuitive. When I first started learning js, I spent most of my time writing nodejs, which made me more familiar with vanilla JavaScript. Recursive copying is really rare in vanilla JavaScript. The most common case is when passing values ​​into functions, and if you pass complex types, you're just passing the address. With this in mind, I never thought that it should be "immutable".

const obj = { one: 1 }
function resolve(val) {
  val.two = 2
  console.log(val) // val = { one: 1, two: 2 }
}
resolve(obj)
// obj = { one: 1, two: 2 }

[Gregoor]

Sounds like the information you're looking for is this. When you consider that v-model is just a shorthand for a prop and event.

Though I agree that the newly added defineModel has made it less clear, that this is the case. Compared to before where one specifically would declare the prop and emit.

I agree, it is kind of the combination of the two. Though then again I've spent most of my last decade full-on in JS, so it's still of ref-passing and mutability is not particularly new to me.

I think where my confusion was, and that's related to @s3xysteak's example, is that I was assigning a reference to another object to the model, which would then do some deep mutation which I did not realize (for a few hours) would mutate the originally referenced model.

For me a warning like: When working with complex values, beware that they are passed by reference, and thus will be mutated directly by v-model components. You might want to use a deep-copy for your v-model values.
(or something along those lines)

[Pentadome]

Unfortunately this is still a pain point with v-model and objects.