Question

I’m working on a web app in Google closure where the structure is something like this:

App
  + Control Pane
  |  + Search Box
  |  + Search Button
  + Result Pane
     + Results
     + Next Page Link

The actual component structure is quite a bit more complex. The important point is that there are many different components all over the component tree that can initiate certain actions. In this example, hitting enter in Search Box, pressing Search Button, or hitting Next Page all require a query to be made.

This is simple enough to handle. Any child anywhere in the component tree can do

this.dispatchEvent(App.EventType.ACTION, ...)

App will be able to listen to it when the event propagates upwards. The problem is the other direction: When App receives data from its query, it must push it to all children.

It seems very brittle for App to try to push directly to Search box and Results, as their location in the component tree is subject to change. What I’d like to do is fire an App.EventType.DATA_RECEIVED event and have all children (and sub-children, etc.) hear it.

The only way to do this in google closure that I’ve been able to find is to make a global public singleton instance of App and use as the source for all App.EventType.DATA_RECEIVED events, or to plumb App through to all children and subchildren.

Both of these are messy and brittle in their own way.

Is there a simple way in closure to dispatch events that bubble downwards?

Answer 1

It’s not a very satisfactory answer, but it’s what I settled on:

There’s no good way to communicate such things down the component tree. Even closure itself bumps into this problem, passing opt_domHelper down the tree to every subcomponent.

My suggestion is to subclass goog.ui.Component for your app and create a myapp.Environment class, which contains both opt_domHelper and other environment variables, such as one event listener designated as the application’s event channel.

It’s not a good solution, per se, but it’s the least of all possible evils. And if you’ve already been dutifully passing opt_domHelper everywhere, then it’s no worse a problem: that plumbing becomes more extensible, and the opt_domHelper itself is hidden from implementors (who now pass around environment instead).