You probably don't need Redux...or Context

A homage to the simplicity of React's internal state

I've been writing React for nearly two years now and it has been without a doubt my favorite tool to work with in the web development space. Much like the software industry as a whole, React is constantly evolving, particularly when it comes to the way it manages state. As of version 16.8, React has rolled out with a 

 that, for all intents and purposes, has flipped the ecosystem on its head. 

My present goal is not to focus on these API changes specifically, rather, their impact on the way we manage React state in our apps. One of the best things about React, in my opinion, is how unopinionated it is when it comes to configuration, tooling and implementation.  However, third party libraries are often the de facto when it comes to app-wide state management, with React itself being deemed as inferior to handling large scale immutable state objects. I hope to build an argument against this mindset being the default when starting from step one with a React app. Of course, I acknowledge that there are definitely going to be scenarios, often associated with scale, where these external tools make our lives as developers easier. This is not a blog post framed around dissuading you from ever using Redux--I personally really enjoy using it and find it to be incredibly powerful given the right circumstances. However, your Todo app or personal site definitely does not need 

nor the more recently popular variant of state management with 

. By the end of this post, hopefully I'll at the very least make you think twice before reaching for such tools in your next React project.

Disclaimer: all implementations of React, regardless of state management method, will include purely hook implementations. If you aren't familiar with hooks, I'd suggest checking out the initial link above before continuing

The most common reason that I see React developers use a third party library like Redux or perhaps a custom implementation of Context is to avoid 

. Prop drilling occurs when a child component requires a specific piece of state, but the parent that houses that state is several levels higher in the component tree. The intermediary components, of course, do not care about such state, so solutions like Redux and Context (I'm aware there's half a dozen others but I'll only speak to those with which I have experience) aim to essentially cut out the middleman. 

Here's a common example of a basic Redux set up to avoid prop drilling (keep in mind that this is a tiny example, so the

The Redux store, in this case, consists of a 

 object. The first question I'd urge you to think about is why any of these things need to be in the store, or in other words, global state. Particularly something as ephemeral as a search string. 

And here's a comparable version using React Context:

Both of these approaches solve the issue of prop-drilling, but I'd urge you to consider the problems or bugs they might introduce over the lifespan of the app. I acknowledge that this isn't really an

 considering it's fetching an end point and rendering some strings, but I think this is how most apps start out, right, especially our side projects. We don't anticipate all the things we'll want to do, the features we'll want to add and whether or not such features will benefit from such a rigid system.

And one step further, how does our app, albeit rudimentary in the case of the above sandboxes, benefit from having the 

 be in global state? This creates a slippery slope in the sense that by storing the episodes in this way, as frontend engineers, we're essentially creating a client-side database with which we must constantly compare our actual database (given there is one of course). We lose our single source of truth merely to avoid an extra request (or two). What is the purpose of this? Some might argue that it allows for easier filtering or querying of client side data to avoid "unnecessary" backend requests, but I'd argue the convenience benefits you perceive on the frontend are meaningless when compared to the potential bugs related to data stagnation that will likely occur between the front and backend of your app. 

Side note, some people might be thinking that if they don't have a backend that this might not apply to them, but I'd push those people to go one step further and ask why, if they're that small, to even have an external state-manager at all.

A common mindset associated with using a state management tool like Redux or Context is that it's all or nothing. In other words, if you're going to use it, use it for 

I, too, used to think this way. However, I've since changed my tune and now approach Redux with the opposite mindset. Now, I firmly believe that you should only add something to your store when you absolutely must. I'd feel confident in saying that this is much less often than you'd think as well, particularly when it comes to handling errors in your application.

Notice how in each of the above approaches, I'm incorporating an error state in my global store. This is a common practice I've seen with Redux and other state management systems, the goal presumably being to tailor a given error message in a way that gives it context (not related to React Context of course) in a particular view. This introduces quite a cumbersome paradigm though because every time we set our error state, we subsequently have to clear it. I've ran into this headache time and time again in massive Redux codebases where nearly every action you create as a developer has to have an inverse, or “clean up”, action to clear the state produced--because it's 

Use React for ephemeral state that doesn't matter to the app globally and doesn't mutate in complex ways. - Dan Abramov in a 

I can almost guarantee you that more of your application consists of ephemeral state than you'd think.

As React developers, there are tons of preachy opinions that constantly overshadow the work we do and how we architecture applications, and there's been many a time where I've incorporated Redux merely because it was a popular tool and I could add it to my resume. But, is it really benefiting our applications?

Right now, if you google "React state management", your results are going to be across the board. "Context makes Redux obsolete!!!", "MobX provides groundbreaking new observer paradigm for state management", "New Redux hooks API brings a total revamp to React state management!" (all of these are made up titles). When I mentioned earlier that one of my favorite parts about React is that it's unopinionated, that certainly does not apply to the React ecosystem and it's one of the more frustrating pain-points of being a React dev in late 2019.

If there's any point that I could get across, it would be that if learning React were a linear path, it should take 

More often than not, I'm afraid the path is 25% of 1 then 3, then 5.

👆🏼Devs who have spent 5 minutes w/ JS & 30 minutes w/ React trying to learn Redux

saying that you shouldn't learn Redux, or even that your application doesn't need Redux. Redux is exceptional in environments that require it, I'm just encouraging you, as a developer, to think about what it is that you're building and if it would actually be enhanced by bringing in an external tool like Redux or rolling your own custom state manager (danger ⚠️) with Context. 

Context specifically is a currently trending solution for managing React state, and I, myself, was a 

 for some time, but then I incorporated this system in a couple production applications. An analogy I think fits when discussing the controversial 

debate is likening Redux to a luxury Mercedes and Context to a 

. Both approaches will get you to where you need to go, it's just a matter of how safe you want, or need to be, to get there.

There seems to be an argument for (or against?) Context revolving around the fact that Redux uses React.Context under the hood. However, the Context API itself wasn't constructed with state-management in mind, rather just as a solution for making a value or values available from one component to another deeper down in the component tree. Regardless of the intent of such a stance, Redux has numerous built in performance enhancers, render bailouts, etc that Context, alone, does not have. Playing off the above car analogy, converting a code base from Redux to purely Context is effectively ripping out the air bags and seat belts from your car. Yeah it's still drive-able, but it's a lot less safe.

Let's revisit the previous two setups using Redux and Context with a similar example using just React:

You should notice a couple differences here. For one, the code is just generally lighter, we've also dropped our 

 component no longer manages its own state--it receives its state, and state setter, from its parent 

 component. This is commonly referred to as "

". Also, because of this parent-child restructure, we get an added benefit of real time search filtering for free. By that I mean that, in the above sandbox, if you search for an episode you're able to instantly see results based on your search rather than having it be based on you clicking the search button.

Seems nice, right? How much did we even have to change to get here? All we did was remove any boilerplate associated with the previous Redux or Context examples and

 from a parent to a child. Notice how, in this scenario, the parent-child prop relationship transpired in a very desirable way. Our parent, 

 component manages all the necessary state for our app. Again, I'll address the fact that this is a very simple app that doesn't really resemble that which we are typically dealing with when making these architectural decisions around state management, but I'd implore you to consider scaling this approach to whatever your problem may be. To elaborate, I mean that just because there are several components that might care about a specific piece of state 

 mean that that piece of state needs to be global. The way in which you compose your components can easily remedy this ailment that you might ascribe to prop drilling. 

I’d even go one step further and suggest that Redux can make us lazy as React developers. When any piece of state can be connected with any component, regardless of its position in the component tree, cohesive component composition is often an afterthought.

 on the power of component composition that I will not attempt to replicate here, but I encourage you to check it out because it is an exceptional remedy to most of the hardships we experience as React devs when passing props and attempting to manage global state.

I've dabbled in several different technologies in my development career, but few get me as excited as React. Now, more than ever, is an excellent time to be a React developer as the lines between front end and full stack are increasingly blurred, which could honestly warrant a blog post of its own. React 

 mode are two other groundbreaking APIs that the team will likely be publishing early next year, adding core functionalities like code splitting and non-blocking rendering that will radically change how React works and significantly enhance both developer and user experiences.

Just because that open source project that got a lot of upvotes on Reddit is using TypeScript, Redux, GraphQL, Apollo Client, etc does not mean that you have to. 

Start simple and add tooling as complexity requires it. React's internal state is perfectly capable of handling most of your run-of-the-mill apps, especially pet projects that are just starting out (and often end up collecting dust in your repo collection). 

Redux can be an incredible tool to add to your React toolkit, I just encourage you to be more mindful of when and how to use it. 

<h1 data-node-type="titlePlaceholder">You probably don't need Redux...or Context</h1><h2>A homage to the simplicity of React's internal state</h2><p>I've been writing React for nearly two years now and it has been without a doubt my favorite tool to work with in the web development space. Much like the software industry as a whole, React is constantly evolving, particularly when it comes to the way it manages state. As of version 16.8, React has rolled out with a <a href="https://reactjs.org/docs/hooks-intro.html" rel="noopener noreferrer nofollow">new hooks API</a> that, for all intents and purposes, has flipped the ecosystem on its head. </p><p>My present goal is not to focus on these API changes specifically, rather, their impact on the way we manage React state in our apps. One of the best things about React, in my opinion, is how unopinionated it is when it comes to configuration, tooling and implementation.  However, third party libraries are often the de facto when it comes to app-wide state management, with React itself being deemed as inferior to handling large scale immutable state objects. I hope to build an argument against this mindset being the default when starting from step one with a React app. Of course, I acknowledge that there are definitely going to be scenarios, often associated with scale, where these external tools make our lives as developers easier. This is not a blog post framed around dissuading you from ever using Redux--I personally really enjoy using it and find it to be incredibly powerful given the right circumstances. However, your Todo app or personal site definitely does not need <a href="https://redux.js.org/" rel="noopener noreferrer nofollow">Redux </a>nor the more recently popular variant of state management with <a href="https://reactjs.org/docs/context.html#contextprovider" rel="noopener noreferrer nofollow">React Context</a>. By the end of this post, hopefully I'll at the very least make you think twice before reaching for such tools in your next React project.</p><p>So let's get into it.</p><div data-panel-type="info" data-panel-position="inline" class="panel panel-type-info panel-position-inline"><div class="panel-container lolwut"><p><em>Disclaimer: all implementations of React, regardless of state management method, will include purely hook implementations. If you aren't familiar with hooks, I'd suggest checking out the initial link above before continuing</em></p></div></div><h3>Prop drilling... ugh</h3><p>The most common reason that I see React developers use a third party library like Redux or perhaps a custom implementation of Context is to avoid <a href="https://kentcdodds.com/blog/prop-drilling" rel="noopener noreferrer nofollow">prop drilling</a>. Prop drilling occurs when a child component requires a specific piece of state, but the parent that houses that state is several levels higher in the component tree. The intermediary components, of course, do not care about such state, so solutions like Redux and Context (I'm aware there's half a dozen others but I'll only speak to those with which I have experience) aim to essentially cut out the middleman. </p><p>Here's a common example of a basic Redux set up to avoid prop drilling (keep in mind that this is a tiny example, so the<em> drilling</em> will be fairly shallow):</p><div data-embed="true" class="embeddedIframeWrapper embed-container editing embed-position-inline" contenteditable="false"><iframe src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fstackblitz.com%2Fedit%2Fredux-avoid-prop-drilling%3Fembed%3D1%26file%3Dindex.js%26hideExplorer%3D1%26view%3Deditor&amp;url=https%3A%2F%2Fstackblitz.com%2Fedit%2Fredux-avoid-prop-drilling%3Fembed%3D1%26file%3Dindex.js%26hideExplorer%3D1%26view%3Deditor&amp;image=https%3A%2F%2Fc.staticblitz.com%2Fassets%2Ficon-664493542621427cc8adae5e8f50d632f87aaa6ea1ce5b01e9a3d05b57940a9f.png&amp;key=c4a3d56b91fa4b36945f1953875308ab&amp;type=text%2Fhtml&amp;schema=stackblitz" sandbox="allow-scripts allow-forms allow-same-origin" frameborder="0"></iframe></div><p>The Redux store, in this case, consists of a <code>search</code> string, an array of <code>episodes</code> (thanks to the lovely <a href="https://rickandmortyapi.com/" rel="noopener noreferrer nofollow">Rick and Morty API</a>) and an <code>error</code> object. The first question I'd urge you to think about is why any of these things need to be in the store, or in other words, global state. Particularly something as ephemeral as a search string. </p><p>And here's a comparable version using React Context:</p><div data-embed="true" class="embeddedIframeWrapper embed-container editing embed-position-inline" contenteditable="false"><iframe src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fstackblitz.com%2Fedit%2Fcontext-avoid-prop-drilling%3Fembed%3D1%26file%3Dindex.js%26hideExplorer%3D1%26view%3Deditor&amp;url=https%3A%2F%2Fstackblitz.com%2Fedit%2Fcontext-avoid-prop-drilling%3Fembed%3D1%26file%3Dindex.js%26hideExplorer%3D1%26view%3Deditor&amp;image=https%3A%2F%2Fc.staticblitz.com%2Fassets%2Ficon-664493542621427cc8adae5e8f50d632f87aaa6ea1ce5b01e9a3d05b57940a9f.png&amp;key=c4a3d56b91fa4b36945f1953875308ab&amp;type=text%2Fhtml&amp;schema=stackblitz" sandbox="allow-scripts allow-forms allow-same-origin" frameborder="0"></iframe></div><p>Both of these approaches solve the issue of prop-drilling, but I'd urge you to consider the problems or bugs they might introduce over the lifespan of the app. I acknowledge that this isn't really an<em> app</em> considering it's fetching an end point and rendering some strings, but I think this is how most apps start out, right, especially our side projects. We don't anticipate all the things we'll want to do, the features we'll want to add and whether or not such features will benefit from such a rigid system.</p><p>And one step further, how does our app, albeit rudimentary in the case of the above sandboxes, benefit from having the <code>episodes</code> be in global state? This creates a slippery slope in the sense that by storing the episodes in this way, as frontend engineers, we're essentially creating a client-side database with which we must constantly compare our actual database (given there is one of course). We lose our single source of truth merely to avoid an extra request (or two). What is the purpose of this? Some might argue that it allows for easier filtering or querying of client side data to avoid "unnecessary" backend requests, but I'd argue the convenience benefits you perceive on the frontend are meaningless when compared to the potential bugs related to data stagnation that will likely occur between the front and backend of your app. </p><p>Side note, some people might be thinking that if they don't have a backend that this might not apply to them, but I'd push those people to go one step further and ask why, if they're that small, to even have an external state-manager at all.</p><h3>Error handling</h3><p>A common mindset associated with using a state management tool like Redux or Context is that it's all or nothing. In other words, if you're going to use it, use it for <strong>everything</strong>.<strong> </strong>I, too, used to think this way. However, I've since changed my tune and now approach Redux with the opposite mindset. Now, I firmly believe that you should only add something to your store when you absolutely must. I'd feel confident in saying that this is much less often than you'd think as well, particularly when it comes to handling errors in your application.</p><p>Notice how in each of the above approaches, I'm incorporating an error state in my global store. This is a common practice I've seen with Redux and other state management systems, the goal presumably being to tailor a given error message in a way that gives it context (not related to React Context of course) in a particular view. This introduces quite a cumbersome paradigm though because every time we set our error state, we subsequently have to clear it. I've ran into this headache time and time again in massive Redux codebases where nearly every action you create as a developer has to have an inverse, or “clean up”, action to clear the state produced--because it's <strong>ephemeral</strong>. </p><blockquote><p>Use React for ephemeral state that doesn't matter to the app globally and doesn't mutate in complex ways. - Dan Abramov in a <a href="https://github.com/reduxjs/redux/issues/1287#issuecomment-175351978" rel="noopener noreferrer nofollow">Redux Github</a> issue</p></blockquote><p>I can almost guarantee you that more of your application consists of ephemeral state than you'd think.</p><h3>Ecosystem pressures</h3><p>As React developers, there are tons of preachy opinions that constantly overshadow the work we do and how we architecture applications, and there's been many a time where I've incorporated Redux merely because it was a popular tool and I could add it to my resume. But, is it really benefiting our applications?</p><p>Right now, if you google "React state management", your results are going to be across the board. "Context makes Redux obsolete!!!", "MobX provides groundbreaking new observer paradigm for state management", "New Redux hooks API brings a total revamp to React state management!" (all of these are made up titles). When I mentioned earlier that one of my favorite parts about React is that it's unopinionated, that certainly does not apply to the React ecosystem and it's one of the more frustrating pain-points of being a React dev in late 2019.</p><p>If there's any point that I could get across, it would be that if learning React were a linear path, it should take <em>roughly</em> this form:</p><ol><li><p><strong>Learn JavaScript</strong></p></li><li><p><strong>No really, I mean learn JavaScript</strong></p></li><li><p><strong>Learn React</strong></p></li><li><p><strong>Build projects in React </strong>(no external state managers)</p></li><li><p><strong>Learn Redux or another third party state manager once you've experienced pain points of not having global state</strong></p></li></ol><p>More often than not, I'm afraid the path is 25% of 1 then 3, then 5.</p><div data-iframe-embed="true" class="embeddedIframeWrapper embed-container" contenteditable="false"><iframe src="https://media.golfdigest.com/photos/5bc4c5f9da13f32f6a55e2ea/master/w_768,c_limit/The-Waterboy.jpg" sandbox="allow-scripts allow-forms" frameborder="0"></iframe></div><p>👆🏼Devs who have spent 5 minutes w/ JS &amp; 30 minutes w/ React trying to learn Redux</p><p>To reiterate, I <strong>am not </strong>saying that you shouldn't learn Redux, or even that your application doesn't need Redux. Redux is exceptional in environments that require it, I'm just encouraging you, as a developer, to think about what it is that you're building and if it would actually be enhanced by bringing in an external tool like Redux or rolling your own custom state manager (danger ⚠️) with Context. </p><p>Context specifically is a currently trending solution for managing React state, and I, myself, was a <a href="https://levelup.gitconnected.com/implementing-redux-style-state-management-with-reacts-usecontext-usereducer-hooks-c1c5596d9619" rel="noopener noreferrer nofollow">passenger on the hype train</a> for some time, but then I incorporated this system in a couple production applications. An analogy I think fits when discussing the controversial <em>Redux vs Context </em>debate is likening Redux to a luxury Mercedes and Context to a <a href="https://en.wikipedia.org/wiki/Ford_Pinto" rel="noopener noreferrer nofollow">1975 Ford Pinto</a>. Both approaches will get you to where you need to go, it's just a matter of how safe you want, or need to be, to get there.</p><p>There seems to be an argument for (or against?) Context revolving around the fact that Redux uses React.Context under the hood. However, the Context API itself wasn't constructed with state-management in mind, rather just as a solution for making a value or values available from one component to another deeper down in the component tree. Regardless of the intent of such a stance, Redux has numerous built in performance enhancers, render bailouts, etc that Context, alone, does not have. Playing off the above car analogy, converting a code base from Redux to purely Context is effectively ripping out the air bags and seat belts from your car. Yeah it's still drive-able, but it's a lot less safe.</p><h3>Oh hey, React</h3><p>Let's revisit the previous two setups using Redux and Context with a similar example using just React:</p><div data-embed="true" class="embeddedIframeWrapper embed-container editing embed-position-inline" contenteditable="false"><iframe src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fstackblitz.com%2Fedit%2Freact-avoid-prop-drilling%3Fembed%3D1%26file%3Dindex.js%26hideExplorer%3D1%26view%3Deditor&amp;url=https%3A%2F%2Fstackblitz.com%2Fedit%2Freact-avoid-prop-drilling%3Fembed%3D1%26file%3Dindex.js%26hideExplorer%3D1%26view%3Deditor&amp;image=https%3A%2F%2Fc.staticblitz.com%2Fassets%2Ficon-664493542621427cc8adae5e8f50d632f87aaa6ea1ce5b01e9a3d05b57940a9f.png&amp;key=c4a3d56b91fa4b36945f1953875308ab&amp;type=text%2Fhtml&amp;schema=stackblitz" sandbox="allow-scripts allow-forms allow-same-origin" frameborder="0"></iframe></div><p>You should notice a couple differences here. For one, the code is just generally lighter, we've also dropped our <code>reducer</code>. Also, the <code>Search</code> component no longer manages its own state--it receives its state, and state setter, from its parent <code>Content</code> component. This is commonly referred to as "<a href="https://reactjs.org/docs/lifting-state-up.html" rel="noopener noreferrer nofollow">Lifting State Up</a>". Also, because of this parent-child restructure, we get an added benefit of real time search filtering for free. By that I mean that, in the above sandbox, if you search for an episode you're able to instantly see results based on your search rather than having it be based on you clicking the search button.</p><p>Seems nice, right? How much did we even have to change to get here? All we did was remove any boilerplate associated with the previous Redux or Context examples and<em> pass some props</em> from a parent to a child. Notice how, in this scenario, the parent-child prop relationship transpired in a very desirable way. Our parent, <code>Content</code> component manages all the necessary state for our app. Again, I'll address the fact that this is a very simple app that doesn't really resemble that which we are typically dealing with when making these architectural decisions around state management, but I'd implore you to consider scaling this approach to whatever your problem may be. To elaborate, I mean that just because there are several components that might care about a specific piece of state <strong>does not</strong> mean that that piece of state needs to be global. The way in which you compose your components can easily remedy this ailment that you might ascribe to prop drilling. </p><p>I’d even go one step further and suggest that Redux can make us lazy as React developers. When any piece of state can be connected with any component, regardless of its position in the component tree, cohesive component composition is often an afterthought.</p><p>Michael Jackson, co-founder of <a href="https://reacttraining.com/" rel="noopener noreferrer nofollow">React Training </a>and co-creator of <a href="https://egghead.io/podcasts/react-router-with-michael-jackson" rel="noopener noreferrer nofollow">React-Router </a>recently published an excellent, <strong><a href="https://www.youtube.com/watch?v=3XaXKiXtNjw&amp;feature=youtu.be" rel="noopener noreferrer nofollow">short video</a></strong> on the power of component composition that I will not attempt to replicate here, but I encourage you to check it out because it is an exceptional remedy to most of the hardships we experience as React devs when passing props and attempting to manage global state.</p><h3>Go forth &amp; create w/ an open mind!</h3><p>I've dabbled in several different technologies in my development career, but few get me as excited as React. Now, more than ever, is an excellent time to be a React developer as the lines between front end and full stack are increasingly blurred, which could honestly warrant a blog post of its own. React <a href="https://reactjs.org/docs/concurrent-mode-suspense.html" rel="noopener noreferrer nofollow">Suspense</a> and <a href="https://reactjs.org/docs/concurrent-mode-reference.html" rel="noopener noreferrer nofollow">Concurrent</a> mode are two other groundbreaking APIs that the team will likely be publishing early next year, adding core functionalities like code splitting and non-blocking rendering that will radically change how React works and significantly enhance both developer and user experiences.</p><p>Just because that open source project that got a lot of upvotes on Reddit is using TypeScript, Redux, GraphQL, Apollo Client, etc does not mean that you have to. <strong>Pre-optimization is the root of all evil</strong>.<strong> </strong>Start simple and add tooling as complexity requires it. React's internal state is perfectly capable of handling most of your run-of-the-mill apps, especially pet projects that are just starting out (and often end up collecting dust in your repo collection). </p><p>Redux can be an incredible tool to add to your React toolkit, I just encourage you to be more mindful of when and how to use it. </p><p>Thanks for listening 👋🏻</p><p>Get in touch with me <a href="https://www.tuckerblackwell.com/" rel="noopener noreferrer nofollow">here</a></p>

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

You probably don't need Redux...or Context

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript