The other day I was browsing LinkedIn when a poll caught my eye
What's your favourite React State Management Library and why?
Naturally, I felt there was an option missing from the poll and left a comment. I replied saying I felt a custom hook with the context API should be enough, let's talk about that.
What is a State Management Library?
Before we look at what state management is we have to agree on what state is. State is a place in memory where we can store some data, anything really. For instance with a checkbox it is either checked or not, true or false, and they are its states, storing a user's name as a string is a state or an array of preferences, the list is endless.
So what is state management? These states/variables need to be interacted with some how. Be it reading the value or setting it. In it's most simple form state management is how you interact with a variable.
In React, states are easy provided you only want to touch them inside the components they were made in. State Management Library's, for React, make it possible to interact with states from anywhere without having to prop drill. This is great and it why these libraries are so popular but is there a better way?
What is the context API?
The context API is a default React hook used to allow data (objects, functions, strings, etc) to be accessed by any child component.
When we use this API in tandem with a custom hook it gets a lot more powerful. We can pass objects with getter and setter functions that can be used read or modify states, as you'd expect, or have functions that allow us to set several states at once or even give us data back in certain formats, perhaps for API calls.
How can we use the context API?
Here I've written a very simple hook to manage storing a person's name. It stores a first and last name, which you can both get and set, it also concatenates the two names into one long name that can be read from context, this is not something you'd ever really need to do but it shows how data can be returned formatted, there is also a function that lets you set both states at once.
Have a look through the code, as I said it's nothing complex but it was only meant to serve as an example of what can be done rather than a template to be followed.
Final thoughts
With all of this power built into React do we need State Management Libraries? Maybe we do or maybe we don't but either way please let me know if you use one and if you do why? I look forward to reading your comments.
Thank you so much for reading.
Latest comments (61)
hello buddy I have a question
I've been using Recoil for a fairly large project, overall it's been really good. One issue is with tests it becomes a little bit of a struggle working with it because you can't read Recoil values in tests. Otherwise, it's been nice to have and a lot easier than other options we looked at.
My favorite is
overmindjswhich I would describe as if somebody who codes regularly rewrotereduxto be actually "ergonomic" without the false functional programming paradigm and with an actual smart TypeScript implementation that works. It still has issues with handling deep nested values, but it is many steps to the right direction.So to answer your question: in very simple cases you don't need a library. If your state grows, you have separate menus with their separate stuff, you will need namespacing, grouping. If you have complex set of state transformations (like having editing mode and then go back to preview mode) you will need a state machine as well (
overmindjsalso has it).I think why people want to get rid of state management libs are coming from design mistakes that made them not ergonomic.
In my humble opinion I use state management only if a way back of the data is needed, e.g. the user is filling in the data and the next step modify the provided data however the user could go back to review the previous data again, cart applications and similar or microfrontend (well here you will find a lot of discussions for and against using data sharing via microservices).
Summing up every application where the user could close the browser and log in again and we want to have ready all the data that was provided.
If we don't have these situations, we are adding extra effort for nothing when the browser and JS tools would be enough (LocalStorage, SessionStorage, Cookies, Cache, etc)
There is a tendency to add state management in every application because it is cool and the applications are overkill.
I hope it helps.
Thanks.
I see some comment against Context API. It's definitely a feasible state management solution. Most of the current state management libraries already use Context API internally. In the end it's all about your use case, no one state management methodology is perfect or fits all purpose. It's all contextual based on factors like.
This article might help you choose the right solution based on your use case. dev.to/swyx/why-do-webdevs-keep-tr...
I think we dont need State Management Libraries. React itself has everything necessary.
Yes, when working for a Medium to big project redux makes life easier. And then redux-saga makes Api calls so much organised. And the biggest difference is Context API is expensive.Context API prompts a re-render on each update of the state and re-renders all components regardless. Redux however, only re-renders the updated components
Slight caveat Context API updates all components that use the specific context updated. Provided you split the data across several contexts and only import the context in components that need access the redraws become a non-issue.
O use a mix of local state, hooks/context and redux at work. We apply them where it makes sense to get the most of them. A complex hook may be better implement as a redux slice, in the same way a slice that doesn't implement async logic and has a fairly simple state is better off as a hook. The key is find the balance where a global state is needed and where you should keep the state local to the component. All depending on the size of tge application. 😉
Zustand?
I use Redux in my React apps for one and only one purpose: to store in app memory the JWT when handling authentication (because saving it in local storage would be madness). And I chose Redux because it was very popular a few years ago.
I also use React Context to store app wide config info like theming, language. However I do not use any other "global" state,
react-queryis more than enough for displaying API results in the frontend.Cheers!
Hey Victor, great post !
Use what makes you happy,
after all, you'll be the one debugging when anything goes wrong in your app
It sounds like you don't need redux 🤔
That may be true, but what else? I need something non persistent to store some app state and I believe Redux is just that: a state container
You can put it with the rest of your app state, or send it through another context provider.
Of course. But I wanted decoupled from my app state because I can reuse this principle for other apps that do not use React. It never actually happened until now but that's what I thought when I decided to use Redux: to keep things completely separated.