🧹 Tech Debt
Our Blazor components and Angular directives are not consistent in whether or not they wrap events fired by the web component or rely on the native event handling.
Angular
Angular discussion split into #1066
For Angular we do not consistently create a @HostListener and then emit to an Angular @Output. Therefore, in some cases, a client needs to listen for an event coming from the web component where $event is of type Event, and in some cases, a client needs to listen for an output emitted by the directive that is of some other type. We should be consistent in our strategy.
Some options:
Always wrap events in Angular outputsNever wrap events in Angular outputsNever wrap events in Angular outputs but export interfaces to help enforce the type of a CustomEvent's detail
This becomes further complicated in cases where the event emitted by the web component has the same name as we'd like to use for the Angular output within the directive (e.g. toggle on the menu button).
Relevant PR discussion: #986 (comment)
Blazor
For blazor we create handlers for custom events but rely on the global events for some such as input and change happening to align with some of our custom events.
Shared consideration
(these are both addressed in the Angular proposal)
Prevent dismiss behavior
If a client needs to modify the event object, e.g. to cancel a cancellable event, then they cannot bind to an Angular @Output, because that does not give access to the Event object. If we want to be consistent in our handling of events and support cancellable events, that may be an argument for never wrapping events.
Delegated events
A common pattern in web development is to rely on event delegation, i.e. register a single event listener on the parent container of list items and not on each individual item. Does supporting event delegation impact the decision (i.e. does Angular @Output support event delegation from children and handle typing well?)
Edit: We have decided on a pattern we should follow in Angular (captured by #1066). Therefore, this issue is now only applicable to Blazor. I've left the Angular section in the description for reference.
🧹 Tech Debt
Our Blazor components and Angular directives are not consistent in whether or not they wrap events fired by the web component or rely on the native event handling.
Angular
Angular discussion split into #1066
For Angular we do not consistently create a@HostListenerand then emit to an Angular@Output. Therefore, in some cases, a client needs to listen for an event coming from the web component where$eventis of typeEvent, and in some cases, a client needs to listen for an output emitted by the directive that is of some other type. We should be consistent in our strategy.Some options:Always wrap events in Angular outputsNever wrap events in Angular outputsNever wrap events in Angular outputs but export interfaces to help enforce the type of a CustomEvent's detailThis becomes further complicated in cases where the event emitted by the web component has the same name as we'd like to use for the Angular output within the directive (e.g.toggleon the menu button).Relevant PR discussion: #986 (comment)Blazor
For blazor we create handlers for custom events but rely on the global events for some such as input and change happening to align with some of our custom events.
Shared consideration
(these are both addressed in the Angular proposal)
Prevent dismiss behavior
If a client needs to modify the event object, e.g. to cancel a cancellable event, then they cannot bind to an Angular
@Output, because that does not give access to theEventobject. If we want to be consistent in our handling of events and support cancellable events, that may be an argument for never wrapping events.Delegated events
A common pattern in web development is to rely on event delegation, i.e. register a single event listener on the parent container of list items and not on each individual item. Does supporting event delegation impact the decision (i.e. does Angular
@Outputsupport event delegation from children and handle typing well?)Edit: We have decided on a pattern we should follow in Angular (captured by #1066). Therefore, this issue is now only applicable to Blazor. I've left the Angular section in the description for reference.