-
Notifications
You must be signed in to change notification settings - Fork 25.3k
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
component events should mask event propagation. #4059
Comments
Is this getting added back to a milestone? Ran into some issues around this the other day. |
A user had the same issue in SO (the output name was renamed in the question, but initially matched the |
* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output. This is currently an issue of Angular 2 - See angular/angular#4059 To prevent the events from bubbling up, we have to stop propagation on change. Fixes angular#544.
* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output. This is currently an issue of Angular 2 - See angular/angular#4059 To prevent the events from bubbling up, we have to stop propagation on change. Fixes angular#544.
* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output. This is currently an issue of Angular 2 - See angular/angular#4059 To prevent the events from bubbling up, we have to stop propagation on change. Fixes angular#544.
* fix(): visual hidden inputs should not bubble change event * Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output. This is currently an issue of Angular 2 - See angular/angular#4059 To prevent the events from bubbling up, we have to stop propagation on change. Fixes #544.
Would be cool to see a overwrite support for events, so that a intuitive usage is possible for custom event behavior. |
@mhevery Is the issue relevant? |
I got caught using a So I guess it would be nice to see this as a compilation error |
Does new labels mean that smth might be changed to make this work? |
Any update on this? This is causing major pain for us because it makes our custom button component prone to misuse (using the native click event instead of our own, which leads to e.g. disabled state being ignored). |
If I create a custom Button Component and define my own (click) event handler, the button click event fires twice. There should be a way to overwrite it. |
@JoostK Wow, so this has been an issue for a while! Wouldn't it be good to document this somewhere? As suggested here... #49114 (comment) Or add some kind of compiler warning or error? What is the full list of names to avoid using? |
The above code creates an issue. It conflates the
change
event from theMyComponent
with the bubblingchange
event from the<input>
.The correct behavior is that the
change
event which is part of the components should filter out the DOMchange
events. Otherwisewill sometimes get the
$event
from theMyComponent
and sometimes from theinput
event.The text was updated successfully, but these errors were encountered: