Should v-model work on components using both v-bind="$attrs" and v-on="$listeners"?

[chrisvfritz]

What problem does this feature solve?

Following this discussion, given a CustomInput component with this template:

<div>
  <input v-bind="$attrs" v-on="$listeners">
<div>

The following currently does not work:

<CustomInput v-model="myValue" />

The problem is that v-model on a component expects a value on input events, but a DOM Event is passed to the listener instead.

What does the proposed API look like?

Option 1: Make v-model smarter

Since I think it's unlikely that anyone will want to use v-model with a DOM Event, perhaps when v-model is used on components, it could check if the argument passed to the listener is instanceof window.Event. Then if it is, use event.target.value instead.

Option 2: Make v-on smarter

Maybe a non-enumerable property could be added to $listeners (e.g. __$listeners__: true, to help v-on detect uses of v-on="$listeners". Then in cases where the $listeners object is passed to v-on and it's used on an element, listeners relevant to v-model could be wrapped:

function (event) {
  listener(event.target.value)
}

But now we're throwing away data. If someone wants to access a keyCode - e.g. with @input instead of v-model - they're out of luck. However, if modifiers were also supported for v-on's object syntax, we could fix this by making .native disable the automatic wrapping behavior.

---

Thoughts? Are there strategies or implications I'm not considering? I'm definitely open to alternatives.

[RobertBColton]

I would say for the first question, I don't care if it works automatically, but that it at least doesn't require another abstraction to accomplish. It should basically work close to how it would work if there was no component.

Literal Values

This is a huge part of the problem for me. I haven't been able to solve it because of a few cases where I want to use enum constants (I know these don't exist in JS, but they do in TypeScript, and I'm using a similar convention in a JS module) in option values.

$event.target.value is always a string, and thus, this solution would not work where the types of the value props should be literals/expressions:

<select>
	<option :value="someExpression">One</option>
	<option :value="someExpression">Two</option>
	<option :value="someExpression">Three</option>
</select>

My proposal

Maybe it would be possible to make v-model="$attrs" work similar to v-bind="$attrs" and be smart enough to not warn about direct prop mutation? What's really needed is some way of getting the prop attributes, why are we only allowed to get access to the non-prop ones?

[nickmessing]

@RobertBColton in your example $event.target._value would work ;) just a hint.

[RobertBColton]

@nickmessing Thanks so much, that does seem to work, but I can't seem to make the following work without a vue warning about directly mutating the value prop.

<template>
    <select class="combo" v-bind:value="value" @input="update"> 
      <option v-for="(item, key) in items" :value="item">{{key}}</option>
    </select>
</template>

<script>
export default {
	props: {
		items: {
			type: Object,
			required: true
		},

		value: {}
	},

	methods: {
		update(event) {
			console.log(event.target._value);
			this.$emit('input', event.target._value);
		}
	}
}
</script>

Ideally I wouldn't want to and do not want to add another value to the data section or similar as it would seem redundant. Is there a way of achieving this simple component without getting too verbose?

[nickmessing]

@RobertBColton, Github issues are not for asking questions, I am most of the time online in official chat (you can try stack overflow or forum too).

[victor-am]

My first impulse when 2.4 got out was to try using v-on="$listeners" and v-bind="$props" with v-model (and got a little sad when it didn't work 😢).

It would be an amazing feature imo 👍

As for the two options, I'm more inclined to agree with the first (seems simpler as far as I understood).

[chrisvfritz]

@victor-am You could experiment with implementing option 2 just for your component, like in this simple example.

[LinusBorg]

I'm not sure this is desirable.

First off, $attrs and $listeners were added to make it easier to pass on these things from a parent component to a child component, to improve the situation for HOC-like components.

Making this work with v-model was not a goal in this original discussion.

Secondly, If we somehow make this work - that you can use v-model on a component with v-model on an element in that component, it feels to me like we essentially recreated inter-component two-way bindings which we originally dropped in Vue 2 for good reason.

Yes, under the hood it's technically still sending events and updating in the parent, but what happened under the hood never was the problem with .sync. It was that it made data flow harder to follow.

Do we re-create this weekness by allowing for a seamless v-model chain through many components down to some nested element in a form? It feels like we would to me.

[chrisvfritz]

@LinusBorg I think you might misunderstand the proposal. There's no state syncing between components, as v-model is only used on the parent component. Check out the example in the issue description, which you agreed should work in another issue.

This comment suggested what you'd like to avoid, with state being maintained in both parent and child, but his use case and proposal isn't related to this feature request.

[LinusBorg]

Oh right, sorry. I misunderstood completely.

[frandiox]

v-model works differently for components and native elements: https://github.com/vuejs/vue/blob/dev/src/platforms/web/compiler/directives/model.js#L47

Therefore, I guess making v-model "smarter" is not trivial. The input event probably needs to be modified manually from the inner component to the outer component @input="$emit('input', $event.target.checked)" (or $event.target.value, etc.).

In my app, I'm wrapping a third party component and just adding custom style. I thought it should work with v-on="$listeners" v-bind="$attrs", but I noticed that adding :value="value" is also required.

I think it is a bit weird that a component with a declared v-model has input in $listeners but doesn't have value in $attrs. Thinking about it twice, I guess this is because value is automatically added to the accepted props due to v-model, and thus it is not included in $attrs (non recognized props) anymore.

However, this.value does not exist unless props: ['value'] is specifically declared. Perhaps value could be added to $attrs if it is not manually specified as a prop?

[chrisvfritz]

I think it is a bit weird that a component with a declared v-model has input in $listeners but doesn't have value in $attrs.

@frandiox I might have misunderstood what you mean, but I'm seeing value in $attrs.

[LinusBorg]

Well, if the child properly declared the prop, I would expect to see it in $props, not $attrs, and that's what's happening.

[chrisvfritz]

@LinusBorg I think @frandiox is suggesting he's seen value automatically registered as a prop on a child component due to the use of v-model on a parent. I haven't noticed that behavior personally.