-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Custom events should not be permeable #6086
Comments
Additional scenario: When I use component components, I often register events that are not generic, but may listen for unintended actions |
options 1
options 2guard native event in the consumer level, (in case you don't have control over Comp) function onChange(event) {
if(event instanceof Event ) return
title.value = e.target.checked
} |
The first sense is that the custom event is only applied to the current component and not triggered by the grandchild component due to the failure to declare
The change event should only be triggered by This doesn't match the first intuition, you guys are talking about a user-side solution, what I'm thinking is why would vue do that? |
I jumped to the workarounds to save you some time, you can check the docs to better understand what is expected from vue when you bind events to a component with a defined emit and without, if you are trying to push a new feature or change of spec, I wish you good luck. |
Thank you for your replies. @lidlanca @KaelWD I'm here to talk about an application scenario <component :is="hit" @change="onChange" />
const hit = Comp1 || Comp2 || Comp3 It may be that The user will find an unexpected response when handling |
I agree that this specific scenario is an easy pitfall to introduce a bug. However it's documented behavior that we could only change in a major release, as far as I can see right now. Though I'd be interested in suggestions For now, what we can do is to better document this pitfall in the docs about We could also consider an eslint rule maybe? |
Thank you for your answer. @LinusBorg I think it could be described clearly in the If you can add eslint rules that would be even better. |
In Vue 2, custom vs. native event listeners are separated via the In Vue 3:
Given that this is documented behavior, we cannot change how it works. It also means that when you attach an event listener to a component, you should not make the assumption that the event is only triggered by component custom events. For the case discussed here - I think it's quite rare to attach an event listener on a dynamic component where not all possible components actually emit that event. When it happens, however, it could indeed be a pitfall. I'm not quite sure how Vue can change its behavior to avoid this without causing breaking changes. |
we can introduce modifiers to vue 3 (prefix). The modifier can configure the type of binding ( native / emit ). to demonstrate the idea, we can look for a prefix that minimize possibility of breaking existing code: <!-- auto -->
<div @Click=handler>1</div>
<!-- auto + case sensitive -->
<div @\Click=handler>2</div>
<!-- emit only -->
<div @@Click=handler>3</div>
<!-- emit only + case sensitive -->
<div @@\Click=handler>4</div>
<!-- native only -->
<div @^Click=handler>5</div>
<!-- native + case sensitive -->
<div @^\Click=handler>6</div> |
add emits to Comp2 if does not need to respond to this event. |
@lidlanca Adding more modifiers to covers these cases would be thinkable in theory, though I'd be hesitant to add more shorthands as it will make the template more and more cryptic. This should likely be discussed in an RFC: github.com/vuejs/rfcs |
I actually started a discussion in RFC |
Vue version
latest
Link to minimal reproduction
https://sfc.vuejs.org/#eyJBcHAudnVlIjoiPHNjcmlwdCBzZXR1cD5cbmltcG9ydCBDb21wIGZyb20gJy4vQ29tcC52dWUnXG5pbXBvcnQgeyByZWYgfSBmcm9tICd2dWUnXG5cbmNvbnN0IHRpdGxlID0gcmVmKCdWdWUzJykgIFxuXG5mdW5jdGlvbiBvbkNoYW5nZShlKSB7XG4gIHRpdGxlLnZhbHVlID0gZS50YXJnZXQuY2hlY2tlZFxufVxuPC9zY3JpcHQ+XG5cbjx0ZW1wbGF0ZT5cbiAgPGgxPlxuICAgIHt7dGl0bGV9fVxuICA8L2gxPlxuICA8Q29tcCBAY2hhbmdlPVwib25DaGFuZ2VcIiAvPlxuPC90ZW1wbGF0ZT5cbiIsImltcG9ydC1tYXAuanNvbiI6IntcbiAgXCJpbXBvcnRzXCI6IHtcbiAgICBcInZ1ZVwiOiBcImh0dHBzOi8vc2ZjLnZ1ZWpzLm9yZy92dWUucnVudGltZS5lc20tYnJvd3Nlci5qc1wiLFxuICAgIFwidnVlL3NlcnZlci1yZW5kZXJlclwiOiBcImh0dHBzOi8vc2ZjLnZ1ZWpzLm9yZy9zZXJ2ZXItcmVuZGVyZXIuZXNtLWJyb3dzZXIuanNcIlxuICB9XG59IiwiQ29tcC52dWUiOiI8dGVtcGxhdGU+XG5cdDxkaXY+XG4gICAgPENvbXAxIC8+XG4gIDwvZGl2PlxuPC90ZW1wbGF0ZT5cblxuPHNjcmlwdCBzZXR1cD5cbmltcG9ydCBDb21wMSBmcm9tICcuL0NvbXAxLnZ1ZSdcbjwvc2NyaXB0PiIsIkNvbXAxLnZ1ZSI6Ijx0ZW1wbGF0ZT5cblx0PGlucHV0IHR5cGU9XCJjaGVja2JveFwiIC8+XG48L3RlbXBsYXRlPlxuIn0=
Steps to reproduce
What is expected?
The content of the h1 tag should not be changed
What is actually happening?
The text in the h1 tag should not be bound to the value of the checkbox
System Info
No response
Any additional comments?
No response
The text was updated successfully, but these errors were encountered: