I did not know all these minutiae about event propagation and how the settings interact and affect things.
Be that as it may, I only read the lit-html and lit-element docs on the subjects and so far have never encountered any problems (regarding events) in working on web components (both, apps-as-components and custom elements). Now that I think of it, probably that is just because...
...I only generate / dispatch my own events to communicate "up the tree"; i.e. I do not generate my own events to communicate within one component.
...all events that I consider part of the API of a component are CustomEvent instances with bubbles:true, composed:true, and a non-standard name (e.g. 'my-component-selection-changed'), that I dispatch on the custom component itself (no re-targeting).
...when I consume these components I do not listen for generic UI events, but only these tedious long names.
...and last, but not least, because I have not had any sophisticated use-cases for events so far.
While my approach is probably flawed in more than 1 way (that I am simply unaware of), so far I've had no surprises. But there is still so much to learn for me in "frontend land" and quite a few surprises will come along, I'm sure 😉
Glad to see you finding success with this pattern! Lots of cool capabilities come from it, for sure. I think in most cases if you are building "app" components, composed: true is actually the way to go. Managing it with non-standard names should keep you out of almost any trouble you might encounter. Even in the case of "reusable" components, this still holds pretty true, in my experience. However, spending the time to decide whether having an event be composed into the rest of an implementing application is API surface or effect bleed, is time well spent.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Excellent post, Westbrook. Thanks for sharing!
I did not know all these minutiae about event propagation and how the settings interact and affect things.
Be that as it may, I only read the lit-html and lit-element docs on the subjects and so far have never encountered any problems (regarding events) in working on web components (both, apps-as-components and custom elements). Now that I think of it, probably that is just because...
CustomEventinstances withbubbles:true,composed:true, and a non-standard name (e.g.'my-component-selection-changed'), that I dispatch on the custom component itself (no re-targeting).While my approach is probably flawed in more than 1 way (that I am simply unaware of), so far I've had no surprises. But there is still so much to learn for me in "frontend land" and quite a few surprises will come along, I'm sure 😉
Glad to see you finding success with this pattern! Lots of cool capabilities come from it, for sure. I think in most cases if you are building "app" components,
composed: trueis actually the way to go. Managing it with non-standard names should keep you out of almost any trouble you might encounter. Even in the case of "reusable" components, this still holds pretty true, in my experience. However, spending the time to decide whether having an event be composed into the rest of an implementing application is API surface or effect bleed, is time well spent.