Some thoughts about React Context

Today I’m going to talk about Context API, one of the most important concepts, API that you need to know when working with React. Okay, let’s get started.

Note that on this blog, I. won’t go into details like “how to set up React Context, how to use React Context” but I just want to share my thoughts about it.

1. Why do we need Context API?

If you’re working with React, you’ll probably have to deal with a very very annoying thing called props drilling. It’s the case when you need to pass some props through some components which don’t really need that props just because its children (or just one) need those props.

Basically, Context API will give you a chance to create some “global stores”, where you can store some props, data which can be shared with multiple components.

2. Compare with Redux

Wait, is that what Redux (or any other state management libraries) is trying to solve, if it’s built-in React, why do we need those state management libraries?

Of course, if it’s only about dealing with props drilling, those libraries wouldn’t have become popular as they are now.

I only have experience with Redux (and a little play-around time with Recoil) so I’ll focus on comparing Redux and Context API only.

a. Features

• With context, there’s nothing more than just a store where you put some global variables in order to be used in multiple components.
• But with Redux, it’s a different story, not only provide a global store but it also serves us other features such as tracking your states through your app (by using Redux extension - it’s very powerful and a must-have extension if you work with Redux, with it, your debugging process will be a lot easier)
  • Another thing worth talking about is that it helps us split logic and actions out of your components (actually with the born of custom hooks, in my opinion, it’s not a “plus-point” anymore)
  • Use middlewares like state logging
  • Moreover, it solves one of the disadvantages of Context API called “Context Hell” (we’ll go deeper into it in the next few minutes).
  • And a lot more stuff, since the “ecosystem” (I don’t know if I can call it like that) is very large with a lot of libraries like redux-thunk, redux-saga, redux-persist,... They change the way of dealing with a lot of problems in React app (but of course, to me, it will make your app bigger and bigger)...

b. Setup

• Because Context API only has one (main) usage, the setup process is very simple, you just need 3 things: Initialize the context, a context provider, and context consumer. Because Context API is a built-in feature in React, you don’t need to install any other libs.
• With redux, one of the biggest reasons I hate when working with Redux is about the setup process, there’s a lot of stuff to be done and each time you have some new action, you have to add to a lot of files (of course you can put all of them in one file and it’s fine, but in the real-life projects and in order to make your app scalable, it’s recommended to split to multi files like app.actions.js, app.reducer.js, app.selector.js,...) But it’s not the end, if you want to interact with other servers and want to fully use Redux, you have to choose to install redux-thunk or redux-saga which makes the logic and the number of lines of code you have to write larger and larger). It’s a nightmare to me.

3. Disadvantage

a. Multi stores

As I mentioned above in Feature section, one of the disadvantages of Context API is that a Consumer can only consume one provider, that said, if you want to use data of different “store” (context), you have to wrap them together like this:

<ThemeContext.Provider value={theme}>
   <UserContext.Provider value={signedInUser}>
          <Layout />
       </UserContext.Provider>
</ThemeContext.Provider>

But what’s not good here?

• Firstly, it’s harder to debug because you have many “global stores”. It’s in contrast to one of the principles in Redux “single source of truth”. The more stores you have, the more careful you have to be.
• Secondly, Another thing worth mentioning here is about performance, by wrapping contexts like onion in the example above if any value of outer context changes which might trigger a re-render of all components it’s wrapping. Of course, most of the time, that’s the behavior we expect our app to be but there are some cases re-rendering inner components which don’t care about changed values doesn’t really make sense and can be a performance issue.

b. Feature limitation

As I mentioned before in the feature section, React Context is nothing but a global store, so React Context is usually used in small projects. When it comes to larger projects, Redux (or other state management libs) is the way to go because of its rich features. Of course, we can still use React Context along with other state management libs. But in my opinion, why do we need another “global store” while we already set up one. Right?

4. Final thought

Despite feature limitations, I’m still in love with React Context. Especially when there are some other libs that can store the data as the global state (i.e Apollo Graphql, React-query,...) as well as the born of custom hooks.

That’s it for today. See you next time. Bye-bye