React contexts are a feature which help you eliminate repetitive prop drilling. Props are often passed down from a parent component to a deeply nested child. This requires each intermediary component to “forward” the prop to the next component in the tree.
Contexts let you pass props through the tree without manually forwarding them at each level. This is particularly useful for data representing top-level application state. User settings, authentication tokens and data cached from API responses are good candidates for the Context API.
This data is often managed by a dedicated state store such as Redux. React’s contexts can often be used instead. This removes a significant amount of complexity within apps where Redux is only used to hold application-level state. Instead of creating an action, dispatcher and reducer, you can use a React context.
An Example Without Context
After a user logs in, you’ll often want to store essential data such as their name and email address in your app’s state. This allows each component to display information about the user without making a round-trip to your API server.
Here’s a naive way of implementing this:
There are three components in the app. The top-level App component keeps track of the current user within its state. It renders the Header component. Header renders UserProfileLink, which displays the user’s name.
Crucially, only UserProfileLink actually interacts with the user object. Header still has to receive a user prop though. This is then forwarded straight into UserProfileLink, without being consumed by Header.
The problems with this approach are exasperated as your component tree becomes more complex. You might forward props through multiple nested levels, even though the intermediary components don’t use the props themselves.
Adding the Contexts API
You can mitigate these issues using the Contexts API. We can refactor the example above to remove the user prop from Header.
The App component will create a new context to store the current user object. UserProfileLink will consume the context. The component will be able to access the user data provided by the context. This is a similar concept to connecting a component to a Redux store.
This refactored set of components illustrates how to use Contexts.
The process starts by creating a new context for the value you’d like to make available. The call to React.createContext(null) sets up a new context with a default value of null.
The App component has been rewritten to wrap Header in UserContext.Provider. The value prop determines the current value of the context. This is set to the user object held in state. Any components nested below the context provider can now consume the context and access the user object.
If you try to access the context from a component that’s not nested within a provider instance, the component will receive the default value you passed to createContext(). This should generally be avoided except for static context values which will never change.
Access to the provided context value is observed in UserProfileLink. The user prop has been removed. The component uses React’s useContext() hook to retrieve the current value of the UserContext. This will provide the user object injected by the App component!
The final change is to the Header component. This no longer needs to forward the user prop so it can be removed entirely. In fact, the user prop is gone from the entire app. It’s now fed by App into the UserContext provider, not any specific component.
Using Context With Class Components
So far we’ve only used contexts within functional components. Contexts work well here as the useContext() hook simplifies accessing the provided data within child components.
You can also use contexts with class components. The preferred way is to set the static contextType class property to the context instance you want to use. React will read this property and set the context property on component instances to the current value provided by the context.
An alternative approach is to render your component’s children within a context “consumer”. You can access each context’s consumer as the Consumer property of the context instance.
You must provide a function as the consumer’s child. The function will be called with the context’s value when the component renders.
Here’s what this looks like:
Using contextType restricts you to one context per component. Context consumers address this issue but can make your component’s render method more opaque. Neither approach is quite as straightforward as the useContext() hook available to functional components.
Updating Context Values
Context values function similarly to props. If a child needs to update context values, add a function to the context. The child could call the function to effect the context value change.
This revised example shows how App now provides a logoutUser function within the context. Context consumers can call this function to update the user in the App component’s state, causing the context’s value to be modified accordingly.
Managing Re-Renders
React will re-render all children of a context provider whenever the provider’s value prop changes. Value changes are compared using Object.is(), which means you must take care when using objects as the context provider’s value.
This component would re-render NestedComponent every time App renders. A new object instance is created for the provider’s value prop each time, so React re-renders the component’s children.
You can address this by lifting the value object into the component’s state. This will ensure the same object is rendered each time:
Summary
React Contexts help you cut out prop drilling by providing a first-class way to pass data down the component tree. Contexts are a good alternative to state libraries like Redux. They’re built-in to React and are gaining traction among projects where Redux is used solely to connect deeply nested components to a shared source of state.
Contexts are intended for “global” data held within your application. They may also hold data for a specific sub-section of your app. Contexts aren’t meant to replace local component state entirely. Individual components should continue to use state and props where the data’s only going to pass up and down a shallowly nested tree.
