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:

class ContextRoot extends React.Component {
  static propTypes = {
    myService: React.PropTypes.object
  }
  static childContextTypes = {
    myService: React.PropTypes.object
  }
  getChildContext() {
    return { myService: this.props.myService }
  }
  render() {
    return React.DOM.div(null, this.props.children)
  }
})

class Content extends React.Component {
  static contextTypes = {
    myService: React.PropTypes.object
  }
  componentDidMount() {
    this.context.myService.addListener(handleChange)
  }
  componentDidMount() {
    this.context.myService.removeListener(handleChange)
  }
  render() {
    return React.DOM.div(null)
  }
})

var myService = new MyService()
var tree = (
  <ContextRoot myService={myService}>
    <Content />
  </ContextRoot>
)
ReactDOM.render(tree, node)

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 = new MyService()
var tree (
  <ContextRoot myService={myDifferentService}>
    <Content />
  </ContextRoot>
)
ReactDOM.render(tree, node)

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.

class Content extends React.Component {
  // ...
  componentWillUpdate: function (nextProps, nextState, nextContext) {
    if (this.context.myService !== nextContext.myService) {
      this.context.myService.removeListener(handleChange)
    }
  }
  componentDidUpdate: function (prevProps, prevState, prevContext) {
    if (this.context.myService !== prevContext.myService) {
      this.context.myService.addListener(handleChange)
    }
  }
  // ...
})

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.

class Content extends ListenerComponent {
  static contextTypes = {
    serviceA: React.PropTypes.object
    serviceB: React.PropTypes.object
  }
  getListeners() {
    return {
      serviceA: handleChangeA
      serviceB: handleChangeB
    }
  }
  render() {
    return React.DOM.div(null)
  }
}

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.

class Content extends ListenerComponent {
  static contextTypes = {
    serviceA: React.PropTypes.object
    serviceB: React.PropTypes.object
  }
  getListeners(context) {
    return {
      serviceA: {
        listener: handleChangeA,
        add: context.serviceA.addMyListener,
        remove: context.serviceA.removeMyListener
      },
      serviceB: handleChangeB
    }
  }
  render() {
    return React.DOM.div(null)
  }
}