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
Top comments (26)
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
useStateoruseReducerfor state, anduseContextif 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.
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.
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:
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.
Thanks for chiming in Mark and thanks for all your work on Redux! π
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
Redux as always. RTK
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.
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.
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.
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.
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...
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. π
I never got to the point where I really need a state management library. The valid use cases would be complex application such as e-commerce website, admin control panel, interactive e-learning system and more.
I don't really consider things like React Query or useSWR to be a complete state management library. They are more like library for simple fetching without headache.
Applications that are not complex would just need to handle input, processing, output and error. For example, a blog needs to fetch data from server then display content to users, a simple chat application would handling messages from other people and sending messages from the user. If the application is this simple, it would not need complex state management solution. At most, it may require some basic solution such as Context, useState, or useReducer.
What exactly do you need it to accomplish? (rhetorical question)
Given your Redux perspective I recommend reading:
not to recommend either XState or Mobx but to better frame what capabilities your candidate solution needs to have.
I'm not so much looking for a solution myself, just curious what folks are using these days. I took David K. Piano's XState course on FEM and it was really great. I haven't tried Mobx though.
I have used Redux for a while, and I am still using it in complex applications.
I am starting giving a change to recoil, and first experience is going so far. I really like the hooks approach to access and modify the global state.
Zustand is the go to state management library for me these days. No need to wrap your component under a Provider.
I am using Redux from past 5 months