Warn when `v-model` is bound on non-existent key

[kay999]

What problem does this feature solve?

Considering this binding:

<input type="text" v-model="data.val1">

This works fine if there is for example { data:{ val1:null }} defined in component-data, but if only { data:{} } is defined it doesn't work correctly because while val1 is created by v-model, it's not made reactive.

By using Vue.set for setting values, this wouldn't be a problem which would make live easiert for certain usecases.

What does the proposed API look like?

No visible change.

But to maintain the actual behaviour this could also be implemented using a modifier like 'set' for example:

<input type="text" v-model.set="data.val1">

This would use Vue.set(data, 'val1', ...) instead of simply generating data.val1 = ...

[LinusBorg]

This is intentional. We think it is better to explicitly define your data strcuture, because then the code of your component is more self-explanatory.

Data mutation should preferably happen in the component's code, not the template, and having v-model create reactive properties dynamially would work against that.

Vue 1 actually did what you proposed and we removed it in 2.0 for the above reason.

[kay999]

While I understand the intention, it also creates lots of boilerplate-code in forms which are used to create data. And it's easy to run into stange behaviour if the backend sends "undefined" data which is then removed by JSON.stringify and leads to the loss of reactivity.

Also for components which create "array-forms" (forms with add/delete-buttons to create multiple rows of data) it always require to providing some data-initialization-code which is often unnecessary if "undefined" should be the standard value.

So maybe providung at least an option like using the "set"-modifier would give the developer the choice how to use it.

[kay999]

It's also a bit inconsistent: If "reactivify by creation" is wanted, providing Vue.set is "wrong" too. But if it exists, why not use it for v-model, too?

And if Vue really wants to enforce this, silently losing reactivity isn't a good thing IMO. In this case v-model should create code which checks for the existence of a key first and raises an error if the key doesn't exits.

[LinusBorg]

It's also a bit inconsistent: If "reactivify by creation" is wanted, providing Vue.set is "wrong" too.

There are situations where it's necessary - and if it's necessary and you use Vue.set, then that behaviour is plainly visible in your code instead of being abstracted away in v-model and hidden in your template.

It's a utility function, and providing it as such is different from integrating this under the hood into one of the most-used features of the framework.

The former enables users to create reactive properties after the fact when they really have to, while the latter accepts this behaviour as the norm and hides it away.

We want to support patterns that lead to readable and maintainable code, even if that means a bit of boilerplate in some situations. Adding your proposed behaviour to v-model would not contribute to that goal, in my opinion.

[kay999]

Then there should at least a check in v-model for non-existing keys, because in the moment this often leads to invisible loss of reactivity if at some point a field isn't created.

This can happen quite easily by setting a value to 'undefined'. Just try to evaluate JSON.stringify({ v1:null, v2:undefined }) to see the problem if you use Vue to edit data provided by some REST service which uses JSON.stringify.

[kay999]

Also the documentation should be updated. Instead of

"Due to the limitations of modern JavaScript (and the abandonment of Object.observe), Vue cannot detect property addition or deletion. Since Vue performs the getter/setter conversion process during instance initialization, a property must be present in the data object in order for Vue to convert it and make it reactive."

there should be a paragraph explaining that it's not because of a "limitations of modern JavaScript" but in fact intended behaviour.

[LinusBorg]

I can agree that a warning here would be helpful and we should look into how to do that or something equally helpful.

However concerning your example: if Your REST API leaves out properties like you describe, and elaves out props that it shouldn't,

• That's a bad API design in my book
• Your client's API lib should take care that the data is normalized.

It should not be the job of the UI (v-model) to add back properties/data that is missing from the data-model. That has to be taken care of in a central place.

[kay999]

On write-back it's of course normalized in the backend (which is still necessary because the backend needs to do validation because it can't trust the data it gets from the frontend). Also sometimes it's useful to distinguish between null and undefined values which only works in Vue if I use code like { value:undefined }.

But because JSON.stringify omits fields with undefined values, it's in fact not easy to do. The only way to do it is to initialize the fields with undefined after receiving them from the backend - which requires a lot of boilerplate code.

[LinusBorg]

Also sometimes it's useful to distinguish between null and undefined values

Agreed - somethimes for those few times:

initialize the fields with undefined after receiving them from the backend - which requires a lot of boilerplate code.

not really:

Object.assign({ valueThatcanbeUndefined: undefined/*,  other such values*/, objectFromAPI}

So generally, that's a one-liner and only a lot of boilerplate if you would deal with objects that had a lot of those kinds of properties.

[kay999]

I also don't see frontend-code as as crucial to the data-modeling than the backend.

So just writing { value:{} } and letting the template define the fields of 'value' via v-model would be less boilerplatey then having to write { value:{ name:undefined, value:undefined, ... } } just because.

And after posting 'value' the backend (where the real data-models live) has to do validation anyway. So I don't see the necessity of Vue forcing me jumping through this hoop...

[kay999]

And even one-liners can become lots of boilerplate if they are necessary in lots of places. It's also not DRY

[LinusBorg]

Also the documentation should be updated. Instead of

"Due to the limitations of modern JavaScript (and the abandonment of Object.observe), Vue cannot detect property addition or deletion. Since Vue performs the getter/setter conversion process during instance initialization, a property must be present in the data object in order for Vue to convert it and make it reactive."

there should be a paragraph explaining that it's not because of a "limitations of modern JavaScript" but in fact intended behaviour.

No. Here you are mxining up two different things. The above pararaph is not about v-model, but any addition of aproperty with normal Javascript means. The limitation is that we technically can't detect when a new poperty is created by obj.newproperty = 'whatever' (no matter if that's done by v-model or you, the developer), so we can't make it reactive. That's why Vue.set() exists.

The choice that we don't use Vue.set() in the implementation of v-model is independent of the fact that we can not detect properties that are added without it and make them reactive "automatically".

[LinusBorg]

I also don't see frontend-code as as crucial to the data-modeling than the backend.

We don't see it as trivial or unimportant, and I don't hink you do either. And our concerns are not about validation, but integrity and predictability.

If v-model always added props that were missing for you, then visiting a form could add a prop without the user doing anything, or as little as clicking into the input and then leaving again (depending on the concrete implementation we would choose).

So now you would have to keep in mind that this property could exist or not exist in various places in your app, depending on wether the user had prevously openened a form that might have added it, or not.

It could make code & data much more brittle and inconsistent, compared to code that would normalize the data that it receives from the API.

That's basically what I meant earlier - better code and data integrity at the cost of a bit of boilerplate when necessary.

[kay999]

If v-model always added props that were missing for you, then visiting a form could add a prop without you doing anything, or as little as clicking into the input

I don't see a problem here, because it's clearly stated in the code by writing 'v-model'. If you look at it from a declarative point of view, using v-model would be sufficient and also DRY.

Of couse you may argue that a template is for output only and shouldn't contain code which changes data, but then having v-model would be wrong anyway. Also I can always use the "long-form"

<input :value="value.field" @input="v => { $set(value, 'field', v) }>

in a template. By allowing this, Vue already goes beyond the simple "the template only shows things" concept. I assume that's because the concept of Vue is more about pragmatism than about enforcing certain paradigms or otherwise templates and models should have been much more decoupled (as in react/flux for example).

Also the "problem" with v-model is simply the "inherited" behaviour of the described "JS limitation". So the quoted paragraph from the docs also applies to v-model. If Vue would detect field addition to all watched objects, v-model would also create new fields - which it in fact already does, it just don't makes them reactive.