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 react@16.3.0, you can still use this API via a polyfill: create-react-context.