Sharing state using React's Context API

Global state in React is synonymous with libraries like Redux. If you ever needed to share state like the current route or data from an API with multiple components, then you may have reached for Redux yourself.

Newer versions of React (16.3+) include a built-in way to share state, which means not having to pull in an external library. This is known as the React Context API and it can be a bit tricky to learn. I hope to provide a simplified explanation and tutorial so that you can quickly add global state to any of your React apps.

The problem we're trying to solve

Before I dive into the Context API, let me describe a problem scenario first.

Let's say that we have a dashboard where a user can update their username. The username is displayed throughout the dashboard so that means the username will be stored in component state and then passed to other components via props.

The username is stored in the state of the Dashboard component, and then passed via a username prop to both of the <WelcomeMessage> and <SettingsForm> components. An additional prop is passed to the form to update the state, which will then re-render the dashboard with the new username.

It's hard to see any problems with this right now. Consider what might happen though when we add more components to the dashboard that are deeply nested.

<Dashboard><WelcomeMessage><MessageList><UserMessage><p>Need to show username here...</p>

In this example I'm attempting to show that <UserMessage> is 3 component levels deep inside the dashboard. To pass the username down to it, we need to do what is known as "prop drilling":

How to use the Context API

It allows you to avoid prop drilling, which means in our earlier example the <UserMessage> component will have direct access to the username state that was initially stored in the <Dashboard> component.

First, the user context is created using createContext(). The values here will be overridden by the UserProvider.

Next, we create a UserProvider component that will serve as the parent component to hold and manage the shared state. Think of this as an equivalent to the <Dashboard> component in our earliest example.

Finally, we export a UserConsumer component which will allow components to access the shared state.

Using the provider

The <UserProvider> component needs to wrap around all components that share state. The simplest way is to add it in your main app component, which is usually the one that gets rendered to the DOM by React.

I'm understanding ReactJS code more the more I look at it. What I really like about this post is you're showing a complicated/confusing way of how a task can be done, then showing how to simplify it using a newer built-in tool (React Context API).

There's a good chance I'll run into a situation like this in the near future and this makes a good piece to refer back to.

It's a great time to be a web developer, lots of innovation and coding standards being improved.

That means a lot to hear that Nick, thank you. I try to be empathic in my tutorials so that someone who is trying to learn something new is not frustrated over complicated wording or assumptions the writer makes of the reader's skills. Showing examples of how I personally did it "the wrong way" and then showing the simpler way I think resonates with a lot of developers.

However, I wonder in which way this is really simpler than using Redux. If you have a limited amount of "shared" data (user is a good example, another one might be a shopping cart) then Context seems to be an attractive approach as it's arguably a little bit simpler than Redux.

However if the number of 'shared' items expands beyond a few then you'll end up with a large amount of 'wrappers' (providers and consumers) al over the place, because what you don't want to do is lump all your shared state into one context provider (if you do that then you're just re-implementing a Redux store in a funny way).

In other words, I have the feeling that "Redux" lets me scale my application better as it grows in complexity.

So, in which scenarios would you recommend using Context rather than React? Both seem to achieve more or less the same goal.

Regarding Hooks, they're fairly new so I wanted to keep the tutorial compatible with most people's codebases. I'll probably do a follow-up for Hooks in the future, but Eduardo's post looks great.

Regarding Redux, I don't think that you should never reach for it, but don't reach for it too early. In one of my recent apps, I decided to forego Redux entirely and the lack of architecture provides flexibility in deciding how everything will evolve. Perhaps Redux or another state library is the solution, but the codebase isn't big enough for me to worry about it yet.

I personally recommend using local state and context until you feel like you need something more powerful or structured. If your app is very complex and also has a large team, then Redux may be a good option for that. For most "non-Facebook-level" apps though, I think staying with context or using a simpler state library built upon context (e.g. Laco, Unstated) will work out really well.

I agree with you to keep state locally within the component, if that piece of state is only needed within that component. So don't make state "global" or centralized if it's needed only in 1 place. No disagreement there.

However ... I didn't know how the Context API works, but now that I know, it I wonder in what way it's really simpler than Redux. If I I understand it correctly, it's just an alternative way to have "global" or centralized state which you can access wherever you want, do I see that correctly?

In that case I would argue that conceptually it isn't really that different from Redux, only "syntactically" and in its mechanics, the way you program it - what it achieves it isn't that different. In the end both sort of look like a glorified way to inject a singleton object with some variables and getters/setters.

In other words, I don't really see the point, unless it cuts down a lot on "boilerplate". Redux also isn't that hard to understand or use, and it's a well known pattern. I'm never really a big fan of "10 different ways to do the same thing", it makes it a lot harder for (new) developers to understand an unfamiliar codebase.

(this is also why I'm generally a fan of the Vue framework - Vue is more opinionated and "batteries included" and mostly advises one recommended way of doing something)

Actually I could make the opposite argument: if you start out with "Context" because your app is 'simple', and later on you realize (as you said) that you'd better use Redux because your app has become more complicated, then you'll have to rewrite all of your context-based code to Redux. Then why not start with Redux right away? Especially because it isn't that hard, at least in my opinion.

So yes, I agree with you when you say "don't reach for Redux too early", but the same applies to Context - don't reach for Context too early. As long as you can manage state locally within components, or you just need to pass it down 1 or 2 levels (via props) then use neither Redux nor Context.

Once you realize that you do need centralized state, then use Redux or use Context, whatever floats your boat (but as I said I don't really see how Context is that much simpler than Redux).

Yes you're correct, there is no difference in what Redux and Context API are made to do.

I also definitely agree with local state. Don't reach for Context or anything global if your components don't need that yet.

The topic of whether Context is actually simpler or if it's better to use a well-known library like Redux is for another discussion I believe. There's also different ways of implementing Redux so I think even if I make some points against Redux, it may not actually apply to every project that uses Redux.

But I still don't see why people say that Redux is complicated, the basics of it are pretty simple. If the problem is "manage shared or global state" and Redux is a well-known solution (and not that hard to understand or implement), then why reinvent the wheel.

Especially since the alternative solutions (based on context or whatever) also tend to increase in complexity with time, and finally you end up with something like ... Redux!

(if you really want a dead simple solution then just import a Javascript module and keep your state there)

to learn and evolve. yes, redux is super simple. react-redux is a bit more complex. redux-thunk/sagas are essentials for good business logic split. but at the end you forget where you need to write this piece of code and where you have to. redux is awesome solution - look at how long it is there and it hasn't changed much. but we are much more powerful now, then 3 years ago.

Yes, sometimes it can be refreshing to try something new or use an alternative way ... if we didn't think like that then we'd still be doing COBOL with punch cards. On the other hand, I sometimes have the feeling that we're going around in circles and essentially end up where we were before :-)