-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In 2.5.1+, v-model cannot be combined with v-on="$listeners" #7042
Comments
The replacing behavior would also be a breaking change though. I think preserving both is more semantically correct, and among the two, the current behavior in 2.5.1+ is the more reasonable (disregarding combined usage with I think the goal really should be how can we make |
Yeah, I'm not a fan of the workaround - it feels a bit hacky. What would you think about suggesting the following pattern instead? <input
:value="value"
v-on="{
...$listeners,
input: event => $emit('input', event.target.value)
}"
> |
@chrisvfritz that's actually reasonable. It's explicitly overwriting the parent input listener. |
Excellent. I've updated the docs and this issue can probably be closed, but I agree that long-term, it really would be nice for Ideally,
|
Version
2.5.1+
Reproduction link
https://jsfiddle.net/bvyo2yra/
Steps to reproduce
See the minimal reproduction.
What is expected?
Previous to 2.5.1,
v-on="$listeners"
could be used in combination with more specific event handlers to create components that could transparently pass events to an element inside them. This worked because the more specific listeners (e.g.@input="$emit('input', $event.target.value)
) were called after the more generic listeners withv-on="$listeners
.What is actually happening?
In 2.5.1, these higher priority listeners are now triggered first, so that if the listener sets a value, it will set the correct value, then the incorrect value, breaking
v-model
.The breaking change was made to solve another issue, so it's probably not ideal to just revert the change. And actually, even the previous behavior was slightly undesirable, as it emitted the same event twice.
To fix both issues, I would actually expect the more specific event binding (e.g.
@input
) to replace the listener of the same name fromv-on
with the object syntax. The more specific listener would then take responsibility for emitting an event at the correct time. That allows the user full, explicit control over the order in which local handlers and handlers from the parent are called.How does that sound to others?
The text was updated successfully, but these errors were encountered: