Components listening to events triggered "above" them in the DOM

[David Ragone]

I've been enjoying the structure that Flight provides to my JS, but am struggling with what is likely a lack of understanding of how to write JS the "Flight" way.

On some pages, I find myself writing a component that is on an element and is responsible for data. It listens for events, fetches data (sometimes based on data in the event), and then emits an event with the updated data. The problem I find is when the logical location (or at least what feels logical to me) for the ui component is "below" that data component. How does the UI component listen for events triggered "above" it?

I'm not sure if this is enough info, but this is a representative DOM structure:

<div class="js-dataComponent">
  <div class="js-uiComponent">
    ...ui stuff goes here...
  </div>
  <div class="js-uiComponent">
    ...ui stuff goes here...
  </div>

  <div class="js-uiComponent">
    ...ui stuff goes here...
  </div>

</div>

In an example like this, there are a few different instances of a uiComponent that each control the contents of whatever is inside their respective divs. A user action will trigger an event, which the respective uiComponent just passes up to the dataComponent. When the dataComponent does its thing and gets new data, how does the uiComponent listen for that?

The only two options I could come up with both feel a bit weird. Option A is for the uiComponent to listen on document. Option B is for the uiComponent to pass a reference to itself in the event data, which the dataComponent then uses to trigger the event on the right DOM node. This feels particularly wrong, given that Flight components should be unaware of each other.

I'd greatly appreciate any help on how to organize my code (and my thoughts) around this issue.

Thanks!

-David

[Tom Ashworth]

Hi David,

The way we do it on TweetDeck and twitter.com is your Option A. Every component is "aware" of two things: it's node (and children) and the document, which we use as a global data bus.

I think this actually a reasonable solution; the components only need to know the events the others emit — in effect, the interface — so they are still well decoupled. After all, they have to communicate some how!

This does mean you are kinda restricted to one instance of any given data component (unless you use some other identity trickery in the events), but I've never found this to be a problem.

Hope that helps!

--

Tom

[David Ragone]

That's really good to know, Tom. I appreciate your answer.

Have you found any issues with managing event names? Do you have particular patterns for namespacing your events to avoid conflicts?