Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/avocode/react-listener-component

Safe listener registration for React context-provided services.
https://github.com/avocode/react-listener-component

Last synced: about 1 month ago
JSON representation

Safe listener registration for React context-provided services.

Awesome Lists containing this project

README

        

# 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:

```javascript
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 = (



)
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.

```javascript
var myDifferentService = new MyService()
var tree (



)
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.

```javascript
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.

```javascript
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.

```javascript
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)
}
}
```