What's your go to state management library these days?

We use Preact at Forem, the software that powers dev.to, but we do not use a state management library, just good old component state.

The last state management library I used was Redux back in Fall of 2018. If you require a state management library for your project, I'm curious which one do you use? Zustand, Redux, Recoil etc. or is it something more like React Query these days?

Also, what do you like/dislike about the state management library you use?

Go!

Photo by Alfons Morales on Unsplash

Comments

[Dan Ott]

I am a HUGE believer in react-query - it handles 99% of the nonsense we used to try to pump into redux. So - for request data, react-query for sure.

After that, it would take a lot for me to use something other than useState or useReducer for state, and useContext if I really need to.

I try to keep state as local as it can be, and that serves me very well most of the time.

[JoelBonetR 🥇]

According to your comment and if I did not get you wrong... You should learn about Reducer Design Pattern which is just what Redux does strictly, so you can understand why it works this way. Also I can understand that Redux works with functional programming paradigm and can be a hard pill to swallow for people not used to it.
The only thing I can say in counter of Redux from an engineering point of view is that it could be less verbose tbh.

Trying to handle a supposedly unified global state as local state is just counter productive and goes against the pattern you're using. So either you didn't understand how it works and why or you understand it but you can't discern whether to use it or not.
There's no tech, design pattern, paradigm or a single thing to rule them all, each tool must be used when it covers the needs.

Also I must add to this comment a very important statement You might not need redux , and you can read the article from one of the team members that developed Redux itself. This can be applied to any of these libs to solve state management.

Things need to be analysed before applying them, otherwise science is left aside and we only obtain the technical part, which is precisely the one that must apply the results of science-based engineering which results in a blind following of things that people involved don't even understand.

[Mark Erikson]

FWIW, I did a rough estimate of React ecosystem "state management market share" a few months ago, and this is what I came up with:

• Redux: 45-50%
• Apollo: 15%
• XState: 8%
• MobX: 7%
• Redux Toolkit: 4.5% (overlaps with Redux)
• React Query and SWR: 2.5% each

I also covered this in my "State of Redux 2021" talk.

On a related note, we recently released our new "RTK Query" API as part of Redux Toolkit 1.6. RTK Query is a data fetching and caching solution built on top of Redux Toolkit. It's similar to and inspired by React Query, Apollo, Urql, and SWR, but has a unique feature set and some nifty capabilities:

redux-toolkit.js.org/rtk-query/ove...

I don't have any hard usage stats on RTKQ so far, but we're seeing a rapid increase in the number of RTKQ questions we answer over in Reactiflux, and have gotten a lot of very positive feedback on it so far.

[Nick Taylor]

Thanks for chiming in Mark and thanks for all your work on Redux! 😎

[sambit sahoo]

In vue 3 it's mostly Pinia (Vuex 5 soon) and zustand in React. Zustand is really good with a very intuitive API. My discussion here

[official_dulin]

Redux as always. RTK

[Dennis Groß (he/him)]

My opinion might be controversy but I avoid any state management framework as long as possible.

I am not a huge fan of the excessive use of the Flux pattern. I just use frameworks-/libraries like redux if I really benefit from cashing data.

But most of the time I like to design my backend API in a way that I can get exactly the information that I need for e.g. a React Component. And then I just fetch the data freshly from the API every time. => no state management required.

Why do prefer this? It just reduces the overall complexity of my application.

That being said, if I have a use case that benefits from cashing I tend to use Redux.

[Emanuel Lindström]

Mostly Redux. Although, I'm beginning to think, if you don't need anything fancy, using Apollo client's local state management is a good idea.

After spending a few days reading the docs and messing around with it, I'm starting to see lots of cool stuff to do with Apollo Client. The new version that is.

[Seth Hall]

React Context often does the trick but using Redux in my current React contract, Zustand in Protege.dev Next.js app, and Vuex in Vue.js. I find React Context and Zustand fairly straight forward and enjoyable, Redux is complicated to set up but fine to use after setup and I LOVE Vuex.

[Mirko Vukušić]

MobX. Love on first sight, for years now. Frankly, still don't get it whay Redux is so popular. For me, MobX is kind of "automagic", like a global class(es) you just set up and (most of the time) forget how it works. It just does.

[Alan Alickovic]

Since there are multiple types of state you would consider choosing the best tool for the problem you are trying to solve.

Here is a brief summary of state types and when to choose which tool:

github.com/alan2207/bulletproof-re...

[Jesse M. Holmes]

I've been getting by with the Context API only, but there have been times where a feature added late has caused a lengthy refactor. That's okay, because I learned more about architecture that way. Without that experience, a developer might end up in some kind of push-pull architecture. 👀

Recently I've experimented with a state library I don't see listed here yet, Akita, which is highly focused on push architecture. Some may find it to be a little too robust, but coming from an Angular background, I didn't bat an eye at the patterns subscribed to with Akita.

I didn't need it for my React project, though. I don't even need Context for the feature I'm working on … yet. 😉