React State Management in 2024

In my POV, React state management libraries can be divided into three groups:

• Reducer-based: requires dispatching actions to update a big centralised state, often called a “single source of truth”. In this group, we have Redux and Zustand.
• Atom-based: splits states into tiny pieces of data called atoms, which can be written to and read from using React hooks. In this group, we have Recoil and Jotai.
• Mutable-based: leverages proxy to create mutable data sources which can be directly written to or reactively read from. Candidates in this group are MobX and Valtio.

Now that we've covered the three main categories of React state management libraries. Let's delve deeper into each one and explore the strengths and weaknesses of each approach. This will help you understand which library best suits your project's needs:

1. Reducer-based Libraries:

Despite its common criticism about being (overly) complicated, Redux has been the most popular state management library since its creation.

+---------------------+
|        Actions      |
+----------|----------+
           |
           v
+---------------------+        +---------------------+
|        Reducers     |        |       Store         |
+----------|----------+        +----------|----------+
           |                              |
           v                              v
+---------------------+        +---------------------+
|        State        |        |     Subscriptions   |
+---------------------+        +---------------------+

Strengths:

• A powerful state machine and time machine. Suppose all of your application states live inside the centralised state (which rarely happens because you might have local states in your components), this formula will exist: UI = React(state). This means a single state value will only result in one UI, so your application will look consistently the same with a specific state. If you backup the entire state somewhere, then dispatch a change like REVERT(pastState) { state = pastState }, your UI will be restored as if it was a captured screenshot.

• The best DevTools support: By updating the state using explicit actions, DevTools can help you point out what, when and how the state changes. You can imagine it like having a Git commit history in your application state, how cool is it?
  

Weaknesses:

• Boilerplate code: even a simple change to your state requires considerable changes in the code.
• Steep learning curve: while it is simple at its core, it is never enough on its own. To truly master Redux, you should know how to use it with other libraries such as Saga, Thunk, Reselect, Immer, or Redux Toolkit. It feels overkill when most of the time, we use generators in Saga just to fetch some data over the network. Modern JS developers tend to use async/await on a day-by-day basis.
• TypeScript: although fully support TypeScript, explicit typing is required most of the time to get typing done for actions, reducers, selectors, and state. Other approaches directly support automatic type inference.

2. Atom-based Libraries:

Instead of putting your whole application state inside a large centralised state, this approach splits it into multiple atoms, each atom preferably as tiny as primitive types or basic data structures like arrays and flat objects. Then, you can use the selector to group related states together later if you need to.

+---------------------+
|     Atoms (State)   |
+----------|----------+
           |
           v
+---------------------+        +---------------------+
|  Selectors (Derived |        |   RecoilRoot        |
|     State)          |        +----------|----------+
+----------|----------+                   |
           v                              v
+---------------------+        +---------------------+
|    State Snapshot   |        |   React Components  |
+---------------------+        +---------------------+

Strengths:

• Leverage React features: this is expected since Recoil and React are both created by Facebook. Recoil works great with cutting-edge React features such as Suspense, Transition API and Hooks.

• Simple and scalable: by using only atoms and selectors, you can still effectively build up a giant reactive application state while having fine-grained control over individual state changes. Lifting state up is now as simple as declaring an atom and changing your useState hook to useRecoilState.

• TypeScript: as a developer who cares about DX as much as a user cares about UI and UX, I found React, Recoil, and TypeScript to be a wonderful combination. In my projects, types are automatically inferred most of the time.

Weaknesses:

• DevTools: if you are looking for an equivalent of Redux DevTools, unfortunately, there isn’t.

• Cannot use state outside of components: although Recoil Nexus is a workaround, this kind of state management library is designed with a (maybe true) assumption that all usage of state happens inside React components.

• Not stable (yet): it has been 4 years, and the latest version of Recoil still has the leading 0 (v0.7.7). I would be glad if, by the time you read this, this information stays irrelevant.

3. Mutable-based Libraries:

Tips: "mutable" and "immutable" refer to how data can be changed after it is created:

• person.age += 1 // mutable
• person = { …person, age: person.age + 1 } // immutable

+---------------------+
|     Observables     |
+----------|----------+
           |
           v
+---------------------+        +---------------------+
|   Computed Values   |        |     Actions         |
+----------|----------+        +----------|----------+
           |                              |
           v                              v
+---------------------+        +---------------------+
|   Reaction (Derived |        |    MobX Store       |
|       Value)        |        +----------|----------+
+---------------------+                   |
                                          v
                               +---------------------+
                               |   React Components  |
                               +---------------------+

Strengths:

• The simplest API: by allowing the state to be mutated directly, no boilerplate code is required to sit between your component and state, unless you want to do so.
• Reactivity and flexibility: dependencies are updated automatically whenever the state changes. This simplifies your application logic and makes it easier to comprehend. Moreover, the proxy-based approach helps minimise unnecessary re-renders. This also translates to smooth performance and a more responsive user experience.

Weaknesses:

• Too much magic: automatic reactivity is a double-edged sword. Race conditions in asynchronous updates can lead your application state to chaos, and debugging the flow of changes can be challenging in complex applications.
• DevTools: again, it seems to me that no alternative has the best tooling support as the reducer-based approach.
• Discrete DX: while React elaborates on the “immutable” approach, having “mutable” data mixed in my project sometimes makes me feel insecure about how I should make changes to my data.

The best choice

Again, the best React state management library for your project depends on your and your team’s specific needs and expertise. Please DON'T:

• Pick a library based solely on project size and complexity. Because, you may have heard somewhere that X is more suitable for a large-scale project while Y is better for a smaller one. Library authors designed their libraries with scalability in mind, and your project’s scalability depends on how you write the code and use the library, not which libraries you choose to work with.

• Apply best practices you learned from one library to another. Putting your whole application state inside a single Recoil atom to achieve a “single source of truth” will only lead to struggling with state updates and issues with performance. As well as defining actions in Redux as if they were setters and dispatching multiple of them instead of batching changes in one commit.

The author's choice

TL;DR: Jotai.

I personally prefer the atomic libraries because of the advantages listed above and my historical painless DX when dealing with asynchronous data fetching and batching loading UI with <Suspense>. What Jotai does better than Recoil is that:

• No key is required. Naming things is tough, and most of the time, you won’t use Recoil’s keys. So why spend time declaring them at all when the libraries can automatically have the keys for you? Here is Recoil’s answer; however, as you can see, people are not quite convinced.
• Performance. A picture is worth a thousand words, and I have 4 of them:


Library	Import cost	LCP
Recoil
Jotai

You might argue that a ~20Kb difference in size does not matter that much, but let’s take a look at a benchmark which was taken on a very old Android device, where sluggishness appears as obvious as bars filled in with a pattern of diagonal red stripes. As you can see, Jotai internal logic requires less overall calculation, which improved my application's LCP, an important Core Web Vitals metric, from ~2.6s to ~1.2s. Nonetheless, this comparison may not take into account other factors that Recoil do better than Jotai (in fact, my knowledge cutoff in this). I just want to say that the Jotai team did a wonderful job there.

I hope this helps!

Comments

[Ghaleb]

The only good thing Redux still has going for it is its Devtools, and that will never be a good enough reason for me to use it. It's the most used tool because it's the earliest robust tool and goes back to the days of class components.

Redux, and central state management in general, make needless globalization the go-to approach to share state, which can quickly turn into a nightmare.

I am convinced that the notion that "central stores are suitable for large projects" is the biggest sham in history. I know from experience that the opposite is more likely to be true.

Central stores are only good for bigger apps only when most state is global by definition. That's it. And I don't know many such use-cases.

[Hồng Phát]

It looks like you and I had the same DX with Redux 😆

[Gongben]

+1

[Ivan Chichkov]

If react offers a context and providers and a way to consume the context values using hooks, you must have really specific needs to go and search for libraries. I believe 90% of projects don't.
So, use your common senses, as first step, then plan further.

[Ivan Jeremic]

I know how context works, and I also wrote context like you do since 2019, you are misunderstanding a few thing and you think you simplifying while in reality you write more code. I bet if you show me a project where you do this I will find tons of unessecary re-renders.

[Ivan Jeremic]

The need is most often the re-rendering the whole app problem. It is better to re-render a few components than the whole tree, that's also the reason why you should work with multiple contexts and not just with one which however becomes hard to manage.

[Ivan Chichkov]

Yes, but you can have as many context providers as you need, as atomic as you need them to be. Provide them as hooks and use them. You'll avoid the dependency to any 3rd party libs and go with pure react. You'll have full control over what you provide and the scope you consume your context in.
Never understood overcomplicating our own work with additional libs if we can achieve our goals with the tools at hand.
There should be real need to solve a problem when you make a decision and first thing is to try to write some code instead jumping on libs wagon ... Libs are good think but they are created to solve problems where they exist.

[Soldeplata Saketos]

but the moment your app needs a global context provider (let's say for global notifications), then the app is screwed with multiple rerenders with Context

[Ivan Chichkov]

It is getting interesting .. and why you think so?
It is up to you when you re-render and what, no? And why any change in whatever of your context hooks will cause re-render of anything you do not change?

[Ivan Jeremic]

It is not as easy as you might think, there is a reason why the number one rule to learn is that Context alone is not a state management solution.

[Soldeplata Saketos]

Well, I think there is a misunderstanding of what is a re-render and what is a re-computation.

A re-computation is when the current component is called again (as a function) and all logic inside is being triggered.
Example:

import * as React from "react";

let externalCounter = 1;
const LoggingComponent = () => {
  const [internalCounter, setInternalCounter] = React.useState(1);
  const [, forceRender] = React.useState(1);
  externalCounter++;
  console.log(
    `current internalCounter is ${internalCounter} and external is ${externalCounter}`
  );
  return (
    <>
      <button onClick={() => setInternalCounter((p) => p + 1)}>
        {internalCounter}
      </button>
      <button onClick={() => forceRender((p) => p + 1)}>Force recompute</button>
    </>
  );
};
export default LoggingComponent;

You will see that the LogginComponent is re-computed and the console log will show that the externalCounter is increasing every time you click the "Force recompute" button. Something similar happens with the useReducer

[Ivan Chichkov]

Hmm, shall you give a thought about what it will be for moderately sized and complex application to get dependent on some libraries that are perfect, but not actually needed?
In summary, React's Context API, when used judiciously with React Hooks, provides a more efficient way to manage state and control rendering behavior in a React application. It offers a simpler and often sufficient alternative to more complex state management libraries for many use cases, especially in moderately sized applications, as I mentioned above.
So, instead of 'first rules' we better use our common senses' as rules often are subjective to the use case or the user.

[Ivan Jeremic]

Do whatever you believe just keep in mind that context is not a state manager.

[Soldeplata Saketos]

I would say that a "moderately sized" app is one which does not have:

• full page overlays, pages with entities (models, data, whatever you call it) that need to be kept in memory while client side navigating to other pages
• actions that trigger changes that affect multiple entities
• more than 20 pages

When you start to have complications like:

• user state management
• shopping carts
• messaging
• global banners, popups, etc
• dynamic theming, translations, and global complex stuff Then it's better to rely in Redux, with RTK, which will provide a super nice DX with all actions centralized, visible state tree, independent slices, re-select, etc

[Adaptive Shield Matrix]

Atom-based Libraries

• Are the best approach, because you do not have to have a global state and can select and just use different state parts (atoms) that you need.
• It blows any other state management solution out of the way by provided developer experience and ease of use.

Atom-based Libraries / Weaknesses

• I would not list DevTools as a downside, since no global state management solution (including react context hooks) allows you to
• all listed waeknesses are about recoil
• Jotai has no weaknesses

Jotai

• ask anyone, who tried different/all state managers, and everyone will tell you that Jotai is the best
• DevTools: jotai provides an api to see/log state updates
• has best and most helpful community/support on github

Generel

20Kb difference is huge, who says it is not?
Only one who can that are people using Nextjs that ships 200kb of JS even in a simple hello world example -> RIP all old/cheap smartphone mobile users (and all users of your app/website in third world countries).

I have written an article, where I touched on state management in react
dev.to/adaptive-shield-matrix/reac...
TLDR: no one should use react build-in state managers. Pick one library - Jotai (recommended) or Zustand and use it exclusively.

Here is some prior art comparing react state managers, about a year ago
frontendmastery.com/posts/the-new-...

[Rense Bakker]

I'm not even sure why recoil still exists tbh... They were really good at SEO for a long time, thats for sure, but that discouraged a lot of people from using atoms, because they would stumble upon recoil first, before jotai, when they searched for atom state management. Luckily that's no longer the case, but we can see that a lot of people still asociate atoms with recoil :(

[Peter Vivo]

My personal solution of state management is useReducer which is a ligthweight replacer of redux. A small 100LOC code npm module written in typescript.
(react-state-factory)npmjs.com/package/react-state-factory[dev.to/pengeszikra/simplify-your-r...]
I give a typescript helper for state handling user can define own - even complex state type - and pass to useReducer.
This type of state is not mandatory use at global statate level, and boiler plate near easy as useState.

[Soldeplata Saketos]

The only problem with this approach (if any) is that the state is updated in every single action, triggering a re-computation of the component, which might lead to re-assignments of any other logic inside the component, and could potentially lead to re-renders if the devs are not using useCallback or useMemo or even memo depending on the case.

So, for this to properly work, you need the devs in your team to be aware of the pitfalls to be avoided.
Example of bad implementation:

const Parent = () =>{
   const [state, dispatch] = useReducer(someReducer, null, { a: 1, b:1, c:1});

  const someComputedValue = a  / c;

  return <div>
                <OtherComponent value={someComputedValue} />
                <button onClick={()=> dispatch({ type: "set_b", payload: 42})}> set b to 42</button>
           </div>
}

As you can see, in this example, OtherComponent would be re-rendered even if values a or c were not modified.

[karanborana1210]

Great article @nguyenhongphat0 . I recently found Jotai, and I am blown away by it's simplicity and DX. But, I am still not sure what will be the best practices for using Jotai in a big project where there is big state object to manage. I haven't got any example of such. If you have any idea on this, please write another article on this, will be of great help 🙌. Thanks!

[Hồng Phát]

Thank you for your compliment, I really appreciate it! I would love to share my specific experience with Jotai and tips that I found useful in another blog. Stay tuned 🤗

[karanborana1210]

Sure @nguyenhongphat0 . I have been using Jotai for a while now, but only for small projects as of now. Haven't been able to decode the best practice to use it in large projects. Will be waiting for your article.

[Vesa Piittinen]

Signals.

Although React is so 2018 that you might want to consider something else. Like, something that actually has been designed to work great with signals.

[Christian GO]

Learned something new, thanks for sharing!

[panfan]

zustand

[Timothy Fosteman]

Good. Always used proxy-based MobX singletons with Typescript. Best combo

[Royan Daliska]

MobX is awesome, I recently use legend state as an alternative. It has everything mobx provide but has less boilerplate

[Martin Zvonar]

I’m so glad to see Jotai as your top choice. I find it so simple and elegant.
I wanted to give recoil a try for a new small project, but I saw it’s still experimental and hasn’t been updated for a year. So I grabbed Jotai again. I wanted to check whether there is some newer better approach and found your article :) My soul restd assured :)
How do you solve a use case when you need to do a derived atom but need a dynamic variable (e.g. categoryId)? Creating the atom dynamically inside the component, memoizing it and using it right away seems a bit clunky. I wonder if there’s a better approach…

[Raí B. Toffoletto]

I don't feel if you need a library in 2024. React manages state fine if you know how to use all of its hooks. Also it is well complemented with SWR or ReactQuery

[幻魂]

try helux github.com/heluxjs/helux
About
A state engine integrates atom, signal, derive, watch and dep tracking, supports fine-grained responsive updates, it is compatible with all react like libs (including React 18)

[Mike Pearson]

How would you categorize StateAdapt?

[Mike Pearson]

state-adapt.github.io/react

[Hồng Phát]

This is the first time I heard about this library! But it looks promising with that RxJS support. Although it doesn't perfectly fit into the Reducer-based group, the way actions show up in Redux DevTools when you use StateAdapt's API hints that it uses a reducer-based approach under the hood.

[Mike Pearson]

Yep, it was originally implemented as a reducer within a Redux-like library.

[idleman]

Typescript is an anti pattern. It is something that sounds good, but is bad. So having that in the list actually make this article lose credibility.

Redux is a good start for most people because it enforce you as developer too think more about how you structure your app and its state than the rest. It is basically event sourcing which is an extreme powerful design pattern.

[Hồng Phát]

I believe that everyone has a unique point of view and developer experience. You might prefer JavaScript over TypeScript, but I would pick TypeScript most of the time. Typing things initially took more time in my projects, but having IDE autocomplete saved me much time later (and that was just one of many TypeScript's awesomeness) 😎

[idleman]

TypeScript does not have types, it has annotations. And yes, it is huge difference. Types you can trust, always, annotations never. If you want types, use webassembly.

And no, TS do not save time. Type or dont type research paper some year ago showed clearly TS cause more bugs and cause longer development times.

[boredcity]

My experience is TS really can hurt initial development time but saves a lot of it when you start adding/removing features and refactoring (usually that's at least 75% of time for a mature product). Annotations can be trusted majority of the time with a sensible config (although I do miss proper types Dart has) and the only alternative I see is JSDoc which is more verbose and has all the same drawbacks.

[idleman]

That is the issue. People, like yourself think annotations can be trusted. As the application and the code grows, bugs tends be introduced because the developer believe he/she can trust the all the annotations. That is what the research paper I mention for you earlier proofs. The more you trust TS, the more problems will come.

Overtime will you learn you code against an interface all the time. Some programmers learn this experience after a couple of years, some it takes 10 years - others understand it first after 20 years. But the faster you learn it, does suddenly the "typing" not make so much sense anymore. The only reason why it was invented in the first place was because of memory alignment together with CPU instructions. Not to help developers to create robust and large applications.

[boredcity]

hmm, the only paper with a name similar to the one you mentioned is this one — and it's definitely pro-Typescript. Could you please share a link to whatever you're using as a basis for your statements, please?

[idleman]

arxiv.org/abs/2203.11115

Analyze the numbers a little bit and you see the problem.

[boredcity]

First of all, thank you for the link! But I'm not sure the paper supports what you're saying, tbh:

The analysis indicates that TS apps exhibit significantly better code quality and understandability than JS apps. Contrary to expectations, however, bug proneness and bug resolution time of our TS sample were not significantly lower than for JS: mean bug fix commit ratio was more than 60% larger (0.126 vs. 0.206), and TS projects needed on average more than an additional day to fix bugs (31.86 vs. 33.04 days).

They actually mention that one of the explanations might be Typescript being chosen for more complex projects. There's also a long section on threats to validity in the paper with some valid concerns. By the way, I'm not 100% convinced if the metrics used make a lot of sense for anything outside open source development with its very specific set of problems and behaviors (but that last one is only my personal opinion, ofc).

On "All other studies are bought by Microsoft" theory (which seems helpful to cement your "I have research behind my back - you don't" argument), paper itself mentions that it contradicts some pre-existing finding. Putting that aside, companies (like Google or Meta, for example) are using Flow / Closure compiler (that have ~ the same perks and drawbacks TS does in regards to type system) without too actively pushing them to anyone — and most of their decisions tend to be data-driven.

All in all, I honestly think it's sensible to question Typescript's usefulness (especially in the light of type anotations proposal) but it would require some better arguments.

[idleman]

It 100% supports what I am saying, you just lack the knowledge to understand it.

significantly better code quality and understandability

It is what developers reports and the author just forward. In other words, it is what developers generally feel, not fact. If it really were true, it should've support in lower bugs and faster development speed heavily for TS vs JS, but that is not the case. That is why you must analyze the numbers.

not significantly lower

Having around ~10% larger codebase, several more commits in average and multiple more days to fix a bug is a lot compared to the alternative to not use it at all. So yes, understand the numbers before you speak and compare every single thing vs JS. The learning curve, the complexity, time on bugs vs features, the extra complexity, the unsafe future (it will very low chance it will be added to the ECMAScript, read the latest meetings notes in the type annotations proposal). TS is just extra risk everywhere.

They actually mention that one of the explanations might be Typescript being chosen for more complex projects.

Sure, or it could be reverse. But the truth is probably either. The realistic possibility is that people who love TS, use TS and people who prefer JS, use JS. And with same skill, JS wins.

PS. Do you know that large companies such as Meta and Google have enough money so they can hire really good developers? Do I need to tell you less experienced and average developers are more productive in JavaScript? Have your ever coach a bunch of junior developers? I doubt you will have the same opinion after 1 year if you did.

[Michael Tharrington]

Heyo! Community Manager speaking — please remember to keep it friendly here!

There's no need for terse accusations like "you just lack the knowledge to understand it" or "understand the numbers before you speak" — if this is your feeling that's fine, but your tone here feels very gatekeeperly and there must be friendlier ways to word this. Disagreements are bound to arise, but remember to follow our Code of Conduct and treat folks with respect.

[boredcity]

Let me make these 3 points and I promise this is my last message in this thread 😅:

1) if the question was whether junior developers should use Typescript for small projects, I'd 100% agree that they probably shouldn't 🙂 That's not how you framed it, though.

2) As an ex-Meta Sr Frontend dev I can vouch for people there not being smarter-than-everyone demigods (well, I sure am not 😅); to make things worse more than a few devs contributing to frontend code have very little experience with JS, TS or React (writing PHP-like Hack or Python code day to day) 🙂

3) I have several years of experience teaching HTML, CSS and JavaScript to complete beginners; I would never suggest they learn TS instead of JS, ofc. But I also taught a course on Typescript to middle/senor developers and most of them found it useful 🤷‍♂️

All in all, as always, "use the right tool for the right job". Small projects (especially by inexperienced teams) likely don't need TS but larger ones might.

[idleman]

There was nothing disrespectful in that answer. It is however disrespectful to me as person you just assume I mean any disrespect/harm by telling the truth. Would write it again if needed. And no, you have no authority to decide if something is disrepectful or not. The only thing you can do is to ban my account, but i don't give a fuck if you are so fucking disrespectful. I don't want to be part of this woke-toxic communitiy anyway.

[Mike Pearson]

I doubt you've ever tried TypeScript for me more than a week. The reason you like Redux is also the same reason some people like TypeScript. And no, it's the opposite of what you say: Everyone I knew when TypeScript got big thought TypeScript sounded terrible. Then after using it fell in love with it. I will personally never go back. I couldn't.

[idleman]

The reason why TS is an anti pattern come from a management perspective. It cause more bugs and slower development speed. No benefit at all from a business point of view. All objective research papers show it, such as type or dont type paper. Only paid research from Microsoft say it is good.

You can still love it though, but just know the marketing for TS is a lie.

[Mike Pearson]

It prevents bugs and increases development speed. There's no need to specify "from business point of view" because that's the default point of view.

Answer honestly: Have you ever used TypeScript for more than a week on a typical application?

[idleman]

False. Every research that is objective (large and not paid by Microsoft) show TS is counter-productive if you aim for high producivity. All the marketing is a complete lie. TS is worst, it has no types, cause more bugs, longer learning curve, has lower development speed.

TS sucks in every way except it cause some developers find the code more readable than regular JS, but that does not mean anything if the end product is more bugs and lower producivity.

Sure, you don't agree with me, but I have research behind my back- you don't.

[Peter Vivo]

My personal research show TS is really helpful even at start phase of hobby project. But also help a lot, when I start transform my real world complex JS react application to TS based one, and even at phase of small amount ts code parts give a great guidance which is improve our development speed a lot.

I know until we don't familiar the use of generic in TS it is harder, but after the whole development process will be much cleaner.

Until I try TS personaly I hated, because with JS I can write code much flexibile, but at that moment I did not work with generals.

TS drawback is the use of generator functions, but correctly declared generator function type, whic can be any amount of yield pont is really crazy things, my advice when we would like to use generator function then best way to forget the TS. But who is using generator function?

[karanborana1210]

Hello @nguyenhongphat0 , want to discuss something about Jotai and it's using strategy. Possible to connect?