JavaScript and the DOM use the Event API to let elements inform their ancestors of things that happen. This works well because each element only ever has exactly one parent (up to the document root), so the path an event takes is linear and reasonably short relative to the size of the document.
But there is no analogue mechanism to propagate events downwards through the DOM:
For a simple example, one can imagine a scenario like this:
<product-search>
<search-box></search-box>
<product-card></product-card>
</product-search>
The API of the search-box element is easy to build with generic DOM APIs: whenever it internally determines that a user's input should start a search, it emits an event of some sort, presumably something like framework:search.
The product-search can then simply listen for said event on itself and automatically becomes very resilient to nesting and other weird HTML shenanigans; users can even use different search components if they're feeling extra creative that day.
Once the product-search component has received the search event, it needs to propagate the state change back down to the product-card. This is surprisingly difficult to do using a generic mechanism.
The problem here is that a) product-search might not want to limit itself to only product-card children but work with any element that conforms to some generic API, b) the element that needs the notification might be deeply nested within the product-search, and c) the component might have a large number of children, making a shotgun approach risky from a performance perspective.
As far as I am aware, there is no feature in the DOM API that fully addresses this. Am I just making things too complicated here? Is there an easy way around it?
My best idea here is a compromise that achieves a) and b) by using querySelectorAll("*") and dispatching a non-bubbling event on every child element indiscriminately.
What do y'all think?
One thought I forgot to add is the possibility to shift the responsibility for the communication to the product-card; it could, when connected, inspect its own context and install an event listener on product-search. This ends up causing the same problems as before: We might want to use a different wrapper, the search wrapper might be at any point in the ancestor chain and installing event listeners everywhere might degrade perforamance and respond to events the component actually doesn't care about.
Top comments (3)
Interesting discussion, my instinct without throwing my brain too deep in a hole is to define
<product-search>with some slot, call itsearch-result, and for the product search component to dispatch a custom event to whatever is in that slot. product-search would trust whatever is slotted to handle that event accordingly, including redistributing the event to specific children if necessary.That does mean elements deep in the hierarchy do depend on some parent telling them what to do, but to me this feels generic enough. I'm at least able to substitute
product-cardwithauroratide-product-doohickeyas long as my component listens to the event dispatched byproduct-search, and as long as my component is allowed to be opinionated about its own children.Maybe I misunderstood your issues, but there are several ways to control the event propagation.
See this post for more information. Event propagation can be convenient, but if you need to be very specific, maybe you apply your events to the children, not the parent.
Or you apply a manual filter in the event routine using Event.srcElement and Event.target, so the event is only executed for a certain type of source element. There are much more properties in the event object you can use (see here). For many events I would not expect any performance issues unless the event is not fired millions of times per second. Usually event handling is very efficient and the event handler is executed in no time, unless you do not apply any DOM manipulation (which is not the case for a skipped event).
Usually "solved" with an EventBus