You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Custom events that are namespaced using the syntax namespace:event will fail. For example, binding to the MDCTabBar:activated event will fail (source).
The problem is Angular will think you are listening to an activated event on a global MDCTabBar event target (source).
Possible Solution
If Angular doesn't know about the event target then assume it is part of the event name, or add syntax to tell Angular to listen to the event name verbatim. I think I saw the ^ syntax in another issue.
e.g.
<!-- hey Angular, don't mess with the event name --><mwc-tab-bar(^MDCTabBar:activated)="onTabActivated($event)"></mwc-tab-bar>
🔬 Minimal Reproduction
Not needed.
🔥 Exception or Error
Unsupported event target null for event activated
🌍 Your Environment
Angular Version:
platform-browser: 7.0.3
Anything else relevant?
Reacted by Burton, John Woodruff and Svyatoslav Zaytsev
<!-- the @ symbol will be replace with a ":" when the event listener is added to the element --><mwc-tab-bar(MDCTabBar@activated)="onTabActivated($event)"></mwc-tab-bar>
As MDCTabBar:activated is a completely valid (if surprising!) DOM Event name, I don't think we should have a special syntax (like (^MDCTabBar:activated) - we should check against a known set (document,window,etc) and otherwise, not mess with it and pass it through...
Re-confirming what was already said - an event with : in its name (ex. MDCTabBar:activated) is a valid event name and some implementations use it!
The bad part here is that Angular uses : to denote a target to add an event to. Changing meaning of : at this point would be a massive breaking change. Not sure how to solve it but this is clearly a bug from a user's point of view.
Any updates? We make extensive use of Lit web components on https://shop.battle.net/ which emit events that contain : (example, blz-video:state-change). It's frustrating that we have to manually add listeners instead of leveraging Angular's binding syntax.
I found a workaround! Looking at the code, I noticed _splitAt() only checks the first instance of character (which is : in this case). So we just have to prefix the event with : to trick the parser.
Using the example from the OP, the workaround looks like:
Activity
[-]Namespaced Custom Events[/-][+][Bug]: Namespaced Custom Events[/+]daniel-nagy commentedon Feb 1, 2019
Here is where it does the parsing: packages/compiler/src/template_parserbinding_parser.ts#L335
Edit: Something like this would work:
daniel-nagy commentedon Feb 1, 2019
If anyone lands here in the future, I came up with this ugly work around.
robwormald commentedon Feb 4, 2019
As
MDCTabBar:activatedis a completely valid (if surprising!) DOM Event name, I don't think we should have a special syntax (like(^MDCTabBar:activated)- we should check against a known set (document,window,etc) and otherwise, not mess with it and pass it through...trotyl commentedon Feb 6, 2019
@robwormald In that sense,
document:activatedas well aswindow:activatedare also completely valid DOM Event names, why shouldn't them being allowed?mhevery commentedon Feb 12, 2019
Would love to have a PR for this (as well as a test)
pkozlowski-opensource commentedon May 29, 2020
Re-confirming what was already said - an event with
:in its name (ex.MDCTabBar:activated) is a valid event name and some implementations use it!The bad part here is that Angular uses
:to denote a target to add an event to. Changing meaning of:at this point would be a massive breaking change. Not sure how to solve it but this is clearly a bug from a user's point of view.tonjohn commentedon Dec 21, 2023
Any updates? We make extensive use of Lit web components on https://shop.battle.net/ which emit events that contain
:(example,blz-video:state-change). It's frustrating that we have to manually add listeners instead of leveraging Angular's binding syntax.tonjohn commentedon Dec 21, 2023
I found a workaround! Looking at the code, I noticed _splitAt() only checks the first instance of
character(which is:in this case). So we just have to prefix the event with:to trick the parser.Using the example from the OP, the workaround looks like: