Seriously - do React hooks replace state containers?
Tags: react, hooks, redux, frontend
Published: 2019-04-25 08:00:39

---
title: Seriously - do React hooks replace state containers?
published: true
description: A wide array of challenges we have to face when developing a React app without a state container
tags: react, hooks, redux, frontend
---

The question about React [hooks](https://reactjs.org/docs/hooks-reference.html) replacing state containers has been coming up more and more often in the React community recently.

{% twitter 1118110824676110336 %}

Nevertheless, the question is not completely out of place. [useReducer](https://reactjs.org/docs/hooks-reference.html#usereducer) and [useState](https://reactjs.org/docs/hooks-reference.html#usestate) handle the state management part, while [useContext](https://reactjs.org/docs/hooks-reference.html#usecontext) can help with its "global nature".

Moreover, a lot of advice floating around sounds as follows:
- start by putting state in your components.
- whenever a piece of state needs to be shared, [lift state up](https://reactjs.org/docs/lifting-state-up.html).
- if prop-drilling becomes an issue, throw it onto context for ease of "global" access.

Armed with this advice, and eager to test it out in practice, let's go ahead and build a React app!

The initial specification from the client looks simple enough: a page with a header (containing a Menu and some user information), a footer, and a sortable/pageable/filterable grid in the main content area. 

![Simple React app wireframe](https://thepracticaldev.s3.amazonaws.com/i/gee6byhavs06fql27b11.png)

Looks really easy &mdash; following the advice above, let's put the state for the grid content and paging close to the grid itself. We also have some state describing what column the grid is sorted by, as well as what filter values have been chosen for each column. So far so good! Development is going really fast and we can quickly iterate on our solution. The component tree looks nice and clean:

![Clean component tree](https://thepracticaldev.s3.amazonaws.com/i/kzufaxlqdv1d2qh5zxa4.png)

At some point we add a toolbar with a settings button, that would open a "settings" dialog and allow to set the number of items per page. Since this state is currently in the "paginator" component, we do not have access to it from the "settings" dialog. No problem, we **lift the pagination state one level up** and pass it down to both the "paginator", the grid and the settings dialog.

![Open settings dialog](https://thepracticaldev.s3.amazonaws.com/i/4hwmkv4d9kve1ir7wwrw.png)

The first Demo to the client is a success! We get some feedback and they would like **some improvements** &mdash; they want to be able to export the grid content to PDF, so we add a new button to the toolbar &mdash; it would open a confirmation dialog with some information about the total number of rows to be exported, so let's **lift this piece of state up** from the grid too, and pass it down to both &mdash; the grid itself, as well as the "report generation" dialog. Manageable so far, but getting messy. Time to document the structure. A stateful component with a couple of `useState` hooks and a `useEffect` hook would look something like this:


![Stateful component](https://thepracticaldev.s3.amazonaws.com/i/3qlr2wujpgj1konubiyf.gif)

The arrows from `state` and `setState` go to and from `JSX`, since we would probably use and set state from there. The same applies to props. `useEffect` closes over props too and has access to state, so let's add those arrows too. We end up with a lot of arrows, but everything is nicely encapsulated inside the component, so let's update our Component Tree diagram:

![Component tree with state sprinkled around](https://thepracticaldev.s3.amazonaws.com/i/llqn0vw5pkt9mvjze6mv.png)

A slack message comes from our **UX team** &mdash; they've convened and decided to have the settings icon down in the footer instead. We've already done some refactoring and lifted the "page size" portion of state up once, but now it would end up right in the root component, since it's the only **common ancestor** of the components that need it. Prop drilling suddenly becomes real, so it seems like it's time to **throw it onto `context`** and access it directly from the components that care. This would add a few more arrows to our component-tree-structure-diagram, but we implement it and move on.

A couple of sprints later an **email from the client** rattles in our inbox &mdash; they've tried the current version of our page and would like some changes:

- it should be possible to choose what columns are to be exported to the PDF report.
- the report should respect the filters chosen in the view.
- the name of the user exporting the report should be displayed in the dialog (remember how this information is now local state in the header?)

Somewhere around this point is where we start slightly hating our life &mdash; things are getting really tough to keep track of! We'll have to move some more chunks of state around, namely to **lift column-state and filter-state up** from the grid, and **lift user state up** from the header to the root component.
Some of the excitement we felt at the start of the project has now worn off, and the rate of progress has considerably slowed down. But things have not gotten completely out of hand, have they? Let's buckle-up and get to it!

We're diligently following the recipe by **lifting state up** or **putting stuff into context** &mdash; which adds more and more arrows to our component tree diagram. We discover that the view becomes slow and laggy, so we fire up our profiler and discover that large portions of our component tree get **unnecessarily re-rendered** too often, so we take a step back and analyze the situation, determine which parts of the view can be memoized and wrap them in `React.memo`. In some cases we get immediate improvements, but others, however, don't seem to be affected by the change since some lambda functions are passed as props. We solve it with the help of `useCallback` instead. It feels a bit like a **chain reaction**: solutions to our previous problems cause new problems, and solutions to those require more solutions, and so on... No matter what, we discover that every one of those problems is solvable as long as we dig deep enough into how React works, so there is no point in complaining. We're done with most of the functionality for now, so let's ship!

![Component tree with context](https://thepracticaldev.s3.amazonaws.com/i/yre9w92an7oucca1h5j8.png)


Before we do, however, we get one more request from the client that just finished testing the latest version and found the "settings" icon to be difficult to find down in the footer. Since they use it often, they would prefer it to be next to the grid, as in the initial version. Hmm... let's try to remember where we put the state for that one... Right, it ended up on context, since we pulled the components apart after some feedback from the UX team a while ago. Now it's going to be close to the grid... so shall we remove it from the context and put it back into local state close to the components? Nah, just leave it as is, you never know when we're going to have to move it again :grimacing:


---

A few months later a new dev comes to work on the project and is given the task of adding information about the current page and page size to the PDF report dialog.

&mdash; New dev (after some detective work): *There is one thing I can't quite wrap my head around... How come pageSize is placed in context?*
&mdash; Old dev: *Can't remember how it ended up there, the dev who did it doesn't work here anymore, but at some point it was probably more convenient, since it was used from the footer or sidebar or something.*
&mdash; New dev: *Really? Isn't it ridiculous that we have to do so much refactoring every time a UI element is moved to a different place?*
&mdash; Old dev: *At least we managed to avoid pulling in a state container!* :woman_shrugging:

Somehow this reminds me of the term "coding by coincidence". Stuff ends up the way it is because "it just happened this way".
This approach contrasts starkly to what software architecture is all about &mdash; having a flexible way of adapting to changing requirements.
Having said that, not every project requires a flexible architecture. If the application is really small, or if it rarely has to change, structuring and architecting it would not be a reasonable time investment.

Hopefully this little (*totally* made up) story helps shed some light on the question **whether hooks replace a state container**. The (slightly elusive) answer is &mdash; _"with hooks, classes or other mechanisms that React provides, it is indeed **possible** to achieve most of what a state container offers"_, but more often than not, the application structure is going to look much more messy than in the image below.

Let's see this again in slow motion:

![Component tree](https://thepracticaldev.s3.amazonaws.com/i/0lnyz928xd0yo3y66xt7.gif)