In a Backbone project I'm working on, every app component and view passes a context object down to any children it creates, which is a copy of the context objec

In a Backbone project I'm working on, every app component and view passes a context object down to any children it creates, which is a copy of the context object it received upon creation, optionally augmented with methods it contributes from itself and other providers. So it's basically a component tree, with an API that grows as you descend down the branches (yet remains distinct between branches). In essence, the context forms a sort of scope that subcomponents can use to communicate with others. By convention, components "import" API calls into themselves in their constructors. This makes it very clear what the dependencies are. The beauty of this setup is that intermediary objects don't have to worry about explicitly mediating the interface between their ancestors and descendants. The only components that have to do any mediation are common ancestors of components that need to communicate across branches, but this mediation can be contained, rather than polluting the entire hierarchy. It's also trivial to mock out the context methods during testing. Similarly, you can use a sort of name-based polymorphism to provide alternate implementations of the context methods, dependent on configuration or parent component, perhaps. It seems to me that a similar scheme would fit nicely with React's model.