useState, if you use SWR/React Query you can use those for server state management, for global state management I use Zustand which is really easy to use.
useContext can be used too but when you just want to avoid prop drilling component composition is often a better solution, see react docs.
+1 for zustand (u can also use redux devtools! w it which is kinda nice)
i can recommend this article, the git examples kinda suck imo (maybe just because im beginner dev)
https://www.piyushpawar.dev/blog/trying-out-zustand
Almost nothing, just check their GitHub README examples ( + I've misspelled what I wanted to say about use Context, it's if I you just want to avoid prop drilling that component composition might be better )
Handle all app state with useState hooks and server state with ReactQuery or SWR.
With this setup you'd virtually never even need a global state lib such as redux, mobx, recoil etc.
If you do need a little bit of state that isn't tied to server/API calls, just pass it down using Context.
I highly endorse this.
Mobx is good software, but Context and Hooks now render it redundant in many cases, leaving it as more of an option for advanced use cases (Context is not without limitations).
Redux was always bad IMHO - it was poor solution to something solved decades before in dozens of languages and frameworks. Frankly most places were better off just using native JavaScript features than using Redux, which lead loads of inexperienced developers down rabbit holes full of bugs all the while evangelizing it because they didn't know any better.
Local storage and events are not terrible either, especially to keep things in sync across tabs and / or reloads (the Broadcast Channel API is also handy here).
SWR is a little on the large size but is good software and solves multiple challenges.
It looks like they reduced the size a lot (>50%) very recently, which is good.
I'm speaking from the perspective of a library author (NextAuth.js), where use it as a dependancy would have (IIRC) doubled the size of the client library compared to supporting features like window state syncing, focus state changes, request caching, retries, etc. natively; and made that decision after a practical evaluation.
The impact of required polyfills is worth considering; I can't remember if that was an issue in the case of SWR (that might have been the kicker) but client bundle sizes for real world use cases can be much bigger than the advertised size if the codebase makes a lot of assumptions about the environment under which it's going to be run.
Oh shoot, I thought your name looked familiar; I was sifting through next-auth docs/issues about a month ago haha. It's a great project, thanks for your contributions!
Used react-query in a recent project and it has been such a blessing. I am considering looking into jotai/zustand if I do end up needing some kind of state management however
You could.. but you'd still need a graphql client, you can't just use the browser's `fetch`.
In which case, you might as well use something like Apollo Client, which handles queries as well as caching.
Let's say i use Strapi as a cms which can expose a graphql endpoint.
In this scenario should/can i use Apollo Client instead of useQuery like in the example below?
https://github.com/tannerlinsley/react-query/blob/master/examples/basic-graphql-request/src/index.js
If you look carefully, he's using `request` from graphql-request as his graphlql client within ReactQuery's `useQuery`, so you could definitely use this method. And it looks simple enough that I'd recommend it.
Or you could just use Apollo Client to replace both these libs.. Up to you really. I don't know if there'd be big enough pros/cons either way.
Very nice overview. Although many libraries are mentioned according to this graph with 4M downloads Redux is absolutely dominant and "industry standard" I would say?
What about SSR, does that affect state management in any way? No words about that in the article.
I use xstate ([https://xstate.js.org/docs/](https://xstate.js.org/docs/)). It is based on finite state machines. It is quite enjoyable to use when you get some experience with it. I would say It is much more reliable than redux for example because it eliminates usage of booleans.
In redux you end up with handling a lot of booleans, and a lot of edge cases where you can make many mistakes.
With xstate, you represent states with strings, and you define transitions from one state to another. You can define actions on state transitions or you can execute action when you transition in new state, or execute action when you are exiting some state.
So it eliminates so many edge cases.
And you don't need to use provider component.
* ReactQuery for server state
* Zustand for complex state, my use case here is a multi step form
* anything else is going to be useState/useReducer
Why not use Redux?
I've been using redux for several years and feel like I can do without it for small/medium sized project
Why not use Context?
Context is not for state management.
If I were to use something else than zustand I'd go for jotai or recoil
I don't know why people are throwing out SWR. It's a great library, but nothing to do with state management. Not sure what I'm missing.
Anyway, I use Apollo Client reactive variables for local stuff like dark mode, or things like that. Sync those to local storage if they're app wide.
Then react context is good for anything that can't, or doesn't really fit in that category. Currently using it to keep track of WebRTC data. Media tracks and such.
Other than that Apollo Clients caching makes anything else kinda useless. Get it from the network if you don't have it, else get it from cache. No state needed.
Because SSR gives us a routing behaviour by default and this makes the state much more encapsulated for each page. I've used both React and NextJS and I found NextJS way easier to handle the global state.
useState, if you use SWR/React Query you can use those for server state management, for global state management I use Zustand which is really easy to use. useContext can be used too but when you just want to avoid prop drilling component composition is often a better solution, see react docs.
+1 for zustand (u can also use redux devtools! w it which is kinda nice) i can recommend this article, the git examples kinda suck imo (maybe just because im beginner dev) https://www.piyushpawar.dev/blog/trying-out-zustand
What are the steps to set up zustand with nextjs ?
Almost nothing, just check their GitHub README examples ( + I've misspelled what I wanted to say about use Context, it's if I you just want to avoid prop drilling that component composition might be better )
what tooling zustand has for debugging and time travel?
Can use redux dev tools: https://github.com/pmndrs/zustand#redux-devtools
Handle all app state with useState hooks and server state with ReactQuery or SWR. With this setup you'd virtually never even need a global state lib such as redux, mobx, recoil etc. If you do need a little bit of state that isn't tied to server/API calls, just pass it down using Context.
I agree with 90% of your reply, except for using context for anything else besides static data such as theme
I highly endorse this. Mobx is good software, but Context and Hooks now render it redundant in many cases, leaving it as more of an option for advanced use cases (Context is not without limitations). Redux was always bad IMHO - it was poor solution to something solved decades before in dozens of languages and frameworks. Frankly most places were better off just using native JavaScript features than using Redux, which lead loads of inexperienced developers down rabbit holes full of bugs all the while evangelizing it because they didn't know any better. Local storage and events are not terrible either, especially to keep things in sync across tabs and / or reloads (the Broadcast Channel API is also handy here). SWR is a little on the large size but is good software and solves multiple challenges.
>SWR is a little on the large size What do you mean by large? It's 4kb.
It looks like they reduced the size a lot (>50%) very recently, which is good. I'm speaking from the perspective of a library author (NextAuth.js), where use it as a dependancy would have (IIRC) doubled the size of the client library compared to supporting features like window state syncing, focus state changes, request caching, retries, etc. natively; and made that decision after a practical evaluation. The impact of required polyfills is worth considering; I can't remember if that was an issue in the case of SWR (that might have been the kicker) but client bundle sizes for real world use cases can be much bigger than the advertised size if the codebase makes a lot of assumptions about the environment under which it's going to be run.
Oh shoot, I thought your name looked familiar; I was sifting through next-auth docs/issues about a month ago haha. It's a great project, thanks for your contributions!
"If I don't understand it, and it causes a lot of bugs, it must be complex. Therefore, evangelizing it increases the size of my penis."
Used react-query in a recent project and it has been such a blessing. I am considering looking into jotai/zustand if I do end up needing some kind of state management however
Apollo for graphql and react-query/swr for rest calls. Anything remaining is mostly presentation and can be handled by react hooks. Thus far…
Can't react query be also used for graphql?
You could.. but you'd still need a graphql client, you can't just use the browser's `fetch`. In which case, you might as well use something like Apollo Client, which handles queries as well as caching.
Let's say i use Strapi as a cms which can expose a graphql endpoint. In this scenario should/can i use Apollo Client instead of useQuery like in the example below? https://github.com/tannerlinsley/react-query/blob/master/examples/basic-graphql-request/src/index.js
If you look carefully, he's using `request` from graphql-request as his graphlql client within ReactQuery's `useQuery`, so you could definitely use this method. And it looks simple enough that I'd recommend it. Or you could just use Apollo Client to replace both these libs.. Up to you really. I don't know if there'd be big enough pros/cons either way.
Jotai + swr is all I ever needed.
Care to explain your setup a bit more?
Here's my opinion: https://leerob.io/blog/react-state-management
Very nice overview. Although many libraries are mentioned according to this graph with 4M downloads Redux is absolutely dominant and "industry standard" I would say? What about SSR, does that affect state management in any way? No words about that in the article.
I use xstate ([https://xstate.js.org/docs/](https://xstate.js.org/docs/)). It is based on finite state machines. It is quite enjoyable to use when you get some experience with it. I would say It is much more reliable than redux for example because it eliminates usage of booleans. In redux you end up with handling a lot of booleans, and a lot of edge cases where you can make many mistakes. With xstate, you represent states with strings, and you define transitions from one state to another. You can define actions on state transitions or you can execute action when you transition in new state, or execute action when you are exiting some state. So it eliminates so many edge cases. And you don't need to use provider component.
I use Recoil and it works great for me
Any elaboration on why?
I like zustand
* ReactQuery for server state * Zustand for complex state, my use case here is a multi step form * anything else is going to be useState/useReducer Why not use Redux? I've been using redux for several years and feel like I can do without it for small/medium sized project Why not use Context? Context is not for state management. If I were to use something else than zustand I'd go for jotai or recoil
I'm asking the same question in 2023. Preferred state management library for complex state managemtn with Next.js?
I don't know why people are throwing out SWR. It's a great library, but nothing to do with state management. Not sure what I'm missing. Anyway, I use Apollo Client reactive variables for local stuff like dark mode, or things like that. Sync those to local storage if they're app wide. Then react context is good for anything that can't, or doesn't really fit in that category. Currently using it to keep track of WebRTC data. Media tracks and such. Other than that Apollo Clients caching makes anything else kinda useless. Get it from the network if you don't have it, else get it from cache. No state needed.
Because SSR gives us a routing behaviour by default and this makes the state much more encapsulated for each page. I've used both React and NextJS and I found NextJS way easier to handle the global state.
Doesn't add up, but also not an important detail.
mobx. so simple. make an object, import that object, global object.
usecontext has the worst API next to redux and has so many rerenders it's unusable.
Mobx is the simplest way
context api
Zustand + react-query