Migrating to React's New Context API

With the recent release of React 16.3.0 came an official context API. You can learn more about the why and how behind this API from my previous blog post: "React's ⚛️ new Context API". Because of this significant change, I'm making an update to my advanced component patterns course on egghead.io to use the new API rather than the old one. As I've been working on updating the course, I've been migrating from the old context API to the new one and I thought I'd show you some of those changes!

In my course, I have a section that shows how to write compound components (a trick I learned from Ryan Florence) that use the context API.

Example Usage

Here's the usage example of the Toggle component that exposes a compound components API:

function Usage(props) {
	return (
		<Toggle onToggle={props.onToggle}>
			<Toggle.On>The button is on</Toggle.On>
			<Toggle.Off>The button is off</Toggle.Off>
			<div>
				<Toggle.Button />
			</div>
		</Toggle>
	)
}

The idea behind the compound components pattern is that it allows you to have components that share implicit state with each other. You can actually use React.Children.map to accomplish it for the simple case, but in this case we need context to share any state at any place in the react tree.

The Old Context API

Here's the version of the implementation with the old context API:

const TOGGLE_CONTEXT = '__toggle__'
function ToggleOn({ children }, context) {
	const { on } = context[TOGGLE_CONTEXT]
	return on ? children : null
}
ToggleOn.contextTypes = {
	[TOGGLE_CONTEXT]: PropTypes.object.isRequired,
}
function ToggleOff({ children }, context) {
	const { on } = context[TOGGLE_CONTEXT]
	return on ? null : children
}
ToggleOff.contextTypes = {
	[TOGGLE_CONTEXT]: PropTypes.object.isRequired,
}
function ToggleButton(props, context) {
	const { on, toggle } = context[TOGGLE_CONTEXT]
	return <Switch on={on} onClick={toggle} {...props} />
}
ToggleButton.contextTypes = {
	[TOGGLE_CONTEXT]: PropTypes.object.isRequired,
}
class Toggle extends React.Component {
	static On = ToggleOn
	static Off = ToggleOff
	static Button = ToggleButton
	static defaultProps = { onToggle: () => {} }
	static childContextTypes = {
		[TOGGLE_CONTEXT]: PropTypes.object.isRequired,
	}
	state = { on: false }
	toggle = () =>
		this.setState(
			({ on }) => ({ on: !on }),
			() => this.props.onToggle(this.state.on),
		)
	getChildContext() {
		return {
			[TOGGLE_CONTEXT]: {
				on: this.state.on,
				toggle: this.toggle,
			},
		}
	}
	render() {
		return <div>{this.props.children}</div>
	}
}

With the old API, you had to specify a string for what context your component would provide in getChildContext and childContextTypes and then specify that same string in the consuming components with contextTypes. I never liked this indirection and normally avoided the problem by making a variable like I do above. In addition, having to attach static properties to the consumers so they could accept the context values wasn't my favorite thing to do either.

Another problem with this API is that it didn't allow values to be updated through a shouldComponentUpdate that returned false. So I had an entire other lesson to demonstrate how to work around that issue: "Rerender Descendants Through shouldComponentUpdate" (hat-tip to Michael Jackson and Ryan Florence for react-broadcast).

The New Context API

The new API doesn't have these problems, which is some of the reason I'm so excited about it. Here's my new version of this same exercise:

const ToggleContext = React.createContext({
	on: false,
	toggle: () => {},
})

class Toggle extends React.Component {
	static On = ({ children }) => (
		<ToggleContext.Consumer>
			{({ on }) => (on ? children : null)}
		</ToggleContext.Consumer>
	)
	static Off = ({ children }) => (
		<ToggleContext.Consumer>
			{({ on }) => (on ? null : children)}
		</ToggleContext.Consumer>
	)
	static Button = (props) => (
		<ToggleContext.Consumer>
			{({ on, toggle }) => <Switch on={on} onClick={toggle} {...props} />}
		</ToggleContext.Consumer>
	)
	toggle = () =>
		this.setState(
			({ on }) => ({ on: !on }),
			() => this.props.onToggle(this.state.on),
		)
	state = { on: false, toggle: this.toggle }
	render() {
		return (
			<ToggleContext.Provider value={this.state}>
				{this.props.children}
			</ToggleContext.Provider>
		)
	}
}

A few things stand out to me in the changes here. As I said, the problems with the old API are gone. Now, rather than the indirection of strings you have explicit components that you must use in order to provide and consume context. You no longer need odd properties to make things work but instead use simple components.

Things are still a tad verbose with those compound components though. Every one of them needs to use the consumer (just like every one of them needed static properties). You can solve that problem (for both APIs) with a render-prop-based Higher Order Component. In this case I wouldn't bother though, it's pretty simple.

The other problem that goes away is updates through shouldComponentUpdate returning false. React's new context API takes care of that for you.

Another thing I love about this is because the consumers are using a render prop API they are highly composable making it possible to do just about anything with them and expose a nice clean API on top because of the dynamic composability of render props (as opposed to the static composability of the old API).

Issues with the New API

One very common pitfall that I'm sure we'll be battling with forever is the importance that the value prop you give to the Provider component is only changed when you want consumers to re-render. This means that doing value={{on: this.state.on, toggle: this.toggle}} in our render method is inadvisable because that creates a new object every time render is called, even if state didn't actually change. Because it's a new object, all the consumers will also be re-rendered.

The impact of this will vary greatly in practice, but in general it's better to provide a value that only changes when state changes (and consumers need to be re-rendered). This is why I say value={this.state}. If you'd prefer not to expose the entire state object to consumers, then you could use this trick I got from Ryan Florence.

One slight issue I have with this is that I have to put the toggle method into state and that feels odd to me, but it's an implementation detail that's not a big deal I think.

Conclusion

After converting a few context using components over to the new API I'm reassured that the React team gave us something brilliant. I love this new API and I'm eager to see how the community embraces it! I hope you enjoy it. Good luck!

P.S. I should note that if you're unable to upgrade to [email protected], you can still use this API via a polyfill: create-react-context.