React Listener Component
Introduction
1. The Problem
When using React contexts, one has to be careful not to get out of sync. Context is not immutable, it can be changed during the components' lifetime (even though it is usually not the case).
Consider the following component tree:
Component static propTypes = myService: ReactPropTypesobject static childContextTypes = myService: ReactPropTypesobject { return myService: thispropsmyService } { return ReactDOM }) Component static contextTypes = myService: ReactPropTypesobject { thiscontextmyService } { thiscontextmyService } { return ReactDOM }) var myService = var tree = <ContextRoot myService=myService> <Content /> </ContextRoot>ReactDOM
The child context of ContextRoot
is recalculated on each update to its props or state. If we were to swap the myService
instance by passing in new props, the child context would reflect the change.
var myDifferentService = var ReactDOM
The issue here is that the child component Content
is now out of sync as it is still listening to the previous service instance even though it is no longer relevant.
2. The Solution
The component has to react to the context change by implementing componentWillUpdate
or componentDidUpdate
in which it compares the old and the new context.
NOTE: It's a good idea to implement both of these methods to gracefully handle update/render failures.
Component // ... { if thiscontextmyService !== nextContextmyService thiscontextmyService } { if thiscontextmyService !== prevContextmyService thiscontextmyService } // ...)
This is quite a lot of boilerplate if we consider that there might be multiple services passed in.
3. The Solution, Reworked
The important pieces in the four lifecycle methods are really only the context keys and the listeners which should be registered. The rest is boilerplate which we should not have to write every time.
Let's request two services from the context and provide the listeners to register.
static contextTypes = serviceA: ReactPropTypesobject serviceB: ReactPropTypesobject { return serviceA: handleChangeA serviceB: handleChangeB } { return ReactDOM }
Now that's awesome. The only limitation it the interface forced on these services: They both have to implement the addListener
and removeListener
methods.
There should be a way to specify the listener registration API for each service.
static contextTypes = serviceA: ReactPropTypesobject serviceB: ReactPropTypesobject { return serviceA: listener: handleChangeA add: contextserviceAaddMyListener remove: contextserviceAremoveMyListener serviceB: handleChangeB } { return ReactDOM }