What I’d like is for this doc about .delegate vs .trigger to be true also for our own events (https://aurelia.io/docs/binding/delegate-vs-trigger#delegate-vs-trigger) but it seems that if I want events to bubble but not cause unexpected runs of event handlers I’ll need to make the event name more specific for the particular custom element.
The whole thing seems a bit fragile… Let’s say I have two different custom elements with slot that expose an expanded event; How am I supposed to know that someone might nest these or how should they know they shouldn’t nest them? And if I want them to be nestable I’ll either need to not bubble the event or use different event names… Or the handler would need to do stopPropagation… It just seems like a complicated decision for each event to make, so is it easier to just force the use of .trigger for our own events (as I have until now)?
What would be the general advice if I were building a plug-in with one or more custom elements that expose events?
How big of a performance gain is it to be able to use .delegate vs .trigger? Is it so much that more specific event names is worth it?
@deap82 the issue you described is how the web work. By default, event will be propagated through the DOM hierarchy unless getting stopped. Because of such, you need to distinguish where an event originates from through event .target. Doing so could be tedious and muddle your business logic with UI code, that’s why we have self binding behavior to help with that. So your template would look like this
That’s very interesting and surely a viable solution when you know about it. I still think though that for some types of events in some types of custom elements I should choose to not let them bubble and document that.
When it comes to the Aurelia documentation I think it would just be a matter of doing some cross references between these sections:
That is what event.stopPropagation() is for, it’s determined by creation time of an event via { bubbles: true }. If needed, you can have some shortcut via custom attribute to stop a custom event from propagated, something like this:
I’m not sure I’m following; I just meant that just like focus and blur I too can choose to not bubble certain events and document that in our internal documentation.
