Forwarding of events from child to parent contexts

[geekdave]

In our apps, we have a "shell" context that is responsible for app-wide events like navigation. With the old Geppetto architecture, we would hold a reference to the shell context on a global namespace, so that any component could dispatch an event like "navigate" onto the shell context, and trigger a nav event.

With the new DI solution, we do not expose context objects directly. So our options are:

1. Use dispatchGlobally (too much noise, since we only want to target a shell context, not every context in the system)
2. Use dispatchToParent (would work if the shell context was the direct parent of a context, but maybe not if there were >2 levels of contexts)
3. Add the ability to register a single context as the "main" context, and create a new API like dispatchToRootContext
4. Implement some kind of "forwarding" mechanism in a Context like so:

forwardToParent: [
  "navigate",
  "logout",
  "foobar"
]

This way, individual components would not need to know how many contexts there are. They would just use the regular dispatch method, and it would be up to that component's context whether or not to forward the event to the parent.

[geekdave]

Some more discussion on this:

Bruce:

Some communications are made through the global context (CMnShellContext in nimbus). It would be great if by default events bubble up to the parent context so we don't need to explicitly dispatch to the global context.

Dave:

Great point, Bruce. Though we may want the ability for a child Context to "whitelist" certain events that should pass-through to the parent context. Events like NAVIGATE or CHECK_DIRTY would be of concern to the parent, while others like LOAD_QUOTE would not. Will bring this discussion to the Github PR. EditDelete

John:

We should be careful with bubbling. That was something that caused many issues earlier on with browsers as there were typically issues with ordering of events, which component handled events, when to continue to propagate or not propagate events, etc. I would prefer to stay simple and not inherit. If you need something, you create a dependency for it directly rather than through indirect means.

Dave:

Let's discuss this in the design review. I think there is a case for a child Context having a "whitelist" of events that it should forward on to the parent context. The "NAVIGATE" event is the best example I can think of. It sounds cleaner to me if a child view can simply dispatch a NAVIGATE event without having to worry about where it gets sent to, and the child context handles forwarding certain whitelisted events to the parent context which can service it.

Bruce:

John, a slight difference from DOM events is here we can give event meaningful names. Less congestion mitigates problems you mentioned in some sense.

John:

I'm not sure I see the difference. I've gotten into problems with just the "click" and "change" events and it's not the number or naming of events. It's managing who receives events and when. For example, if you have a hierarachy of views (root <- child <- subchild) and the subchild issues an event, can the child catch and handle the event and prevent further propagation? What if both the child and root register handlers for the event, are they ordered? If so, what's the right order? Doesn't it depend on the event? Can an event be dispatched outside the view hierarchy (e.g. service returning data)? If so, what happens then? Just feels a bit complex unless we really need it.

[creynders]

Resolved in #62