DEV Community

Sharing state using React's Context API

Sunny Singh on February 17, 2019

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

Read full post

Nick Hiebert • Feb 23 '19

Great post, Sunny!

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.

Sunny Singh • Feb 23 '19

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.

Nick Hiebert • Feb 23 '19

No problem at all Sunny. I'll let you know if anything comes up through my journey learning React .

Sunny Singh • Feb 23 '19

Also definitely let me know what parts of React you found difficult to understand while learning it. I would love to tackle those topics in future articles.

Alex Vechy • Feb 18 '19

Seems like it's common to avoid Redux :D
I had exactly same thing: dev.to/lexswed/building-global-sto...

Anna Simoroshka • Feb 18 '19

I am also making my own redux-like state management with context (and hooks) 😀

leob • Feb 21 '19 • Edited

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)

Alex Vechy • Feb 21 '19

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.

leob • Feb 21 '19

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

Sunny Singh • Feb 18 '19

Haha yeah. I think most people jump on the Redux hype train, realize that they over engineered their apps, and then look for simpler options.

I like that your post goes more into how to create a store. I find the context API hard to understand at first so I decided to make a basic intro into using it.

leob • Feb 22 '19

Folks, maybe this is the solution ... medium.com/swlh/no-boilerplate-glo...

leob • Feb 21 '19

Good explanation ... I believe the new "Hooks" API also supports Context, see this article: dev.to/oieduardorabelo/react-hooks...

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.

Sunny Singh • Feb 21 '19

Thanks leob.

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.

leob • Feb 21 '19 • Edited

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

Sunny Singh • Feb 21 '19

Ah I see what you mean.

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.

Mike Dodge • Feb 7 '20

Sunny, excellent article on context! This is something I have been struggling with a lot lately. I'm running into an issue where I'm fetching data from an API and loading it into context to use in my app. But my app tries to use the data before it's available and getting 'undefined' errors. Any ideas how to overcome this? Looks like miodrag is having a similar issue.

Sunny Singh • Feb 8 '20

Thanks Mike! It's ok for the data to be undefined before it's available, that's how you are able to detect loading states. I suggest you return some default content or a loading spinner in your component's render so that the rest of the component does not try to reference something like data.user.name before it's set.

miodrag • Jul 17 '19

Hi, do you wish help me in next problem. My code:

function noviData() {

fetch("http://localhost:3000/posts.json")
    .then(response => {
        return response.json();
    })
    .then(data => {
        console.log("parsed json of function noviData", data);
        //alert([json.name, json.id, json.email]);
    })
    .catch(function(ex) {
        console.log("parsing failed", ex);
    });

}
How can use data of this function from some another function or component or const or context?
If you have some advice or tutorial examples.
Regard
Mr.Miodag

Mika Kaakinen • Jul 5 '19

An excellent article! Thank you, Sunny!

Tom Moran • Oct 11 '19

Hey Sunny,

Nice article and working on refactoring a simple app away from prop drilling.

In your example, you're only managing a single state attribute but to use another example, what if I needed to track 15 attributes/object in global state. Is the expectation that I would need to declare the 15 object properties and associated update functions in both the user context and the user provider? Are there other techniques where I could create a single object and then update that object on a property by property basis (aka nested object compared to a single object property)?

I know there's a valid reason, I'm just failing to grasp why we have to define the UserContext props and methods in the UserContext object. Is that essentially enforcing the structure that get's implemented in the provider? Basically wondering why there is this "write twice" approach.

Jared Huffstutler • Mar 6 '20

As an experienced programmer and web developer, I found this article extremely useful for understanding the basic concepts of the context API. It is also "simple" enough for beginners. This article is thorough, complete, and explains things very well. Thank you and great job!

Andres Guerrero • Sep 18 '19

Thanks man. Really helped me!

Ciaran Whyte • Nov 14 '19

Hi Sunny, great article, thanks

miodrag • Jul 17 '19

I am use your sample and discover how can have more inputs in app. But, and how can use sample for make message, there have text, image, and user name