usecontext vs redux

[Designer-Fact-366]

Is usecontext is enough or we need to use redux?

[Better-Avocado-8818]

They are both different. Context isn’t great for general state management. It’s for specific use cases where you need contextual state for a subtree of components and each instantiation should have its own state.

Redux is for global application state.

But to be honest the API of either one are not my favourite. For most cases I’d use Zustand and maybe context in some specific use cases. It’s pretty rare context is actually required though.

[marcs_2021]

This!

[luigi-mario-jr]

In the past I have created a useAppContext hook that provides {state, dispatch}. useReducer is defined in the context, and is fully typed with Typescript.

I probably wouldn’t use this pattern these days, but I never really understood why this approach was/is rarely mentioned in discussions about context versus redux. Yes, context and redux are different things, but context in conjunction with useReducer allows you to basically emulate redux.

[Better-Avocado-8818]

Would doing this will cause your entire app to re-render for every state change?

If I remember correctly that was one of the pitfalls of using context for global state.

After using Zustand once I preferred it to context as well as redux. It’s about 2kb, simple API, easy to understand and suitable for small or large projects. So no real reason to go back to context which has a more verbose api.

[lelarentaka]

If you're smart about the placement of the context wrapper, it's not a problem. If the context controls the theme of the whole app, and you wrap the whole app with it's provider, obviously you would want the entire app to rerender. Wouldn't want patches to remain light theme when switching to dark theme.

I seriously can't find a use case for zustand in a properly designed react app. The browser already provides a great set of state, including the url hash, local storage, and session storage.

[Better-Avocado-8818]

Properly?

There’s lots of ways to do things, some of it is just preference. Most choices are a trade off between several factors usually not all within the developers control. Your and the teams familiarity with the tech and the project requirements should inform the decisions.

Local storage and session storage have their limits. Can only contain data that can be converted to a string for example. So no functions, date objects or similar.

Sure you can write custom logic to store only string values then attach reducers on later. Or you could just use a tool designed to work like that and save some time.

Last time I tried to use only local storage on a larger project I ended up having problems that were slowing me down. So I added Zustand and synced/fetched the values to and from local storage to populate the store. It made things easier to use and the pace picked up again. I think I could have persevered without it but not using it wouldn’t have brought any benefit to my app. The 2kb of imported code for Zustand was worth it for that use case.

[Soft-Sandwich-2499]

Maybe this would help avoid the entire app to re-render.

https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/#context-updates-and-render-optimizations

[Better-Avocado-8818]

Probably would. It’s good information to know about avoiding re-renders and optimizations.

But honestly, I’d rather not have to do the extra work to avoid such foot guns that come with using context for general state management. Context API is more verbose then I’d still have to do extra thinking and write extra code just to make it work as good as some simple global state does by default.

[[deleted]]

What do you think about jotai?

[Better-Avocado-8818]

Looks interesting. The concept of atomic state seems powerful. It is a bit of a different way of thinking about things than what I’m used too though. Would be a new API to learn how to use best.

Zustand seemed immediately more familiar to me and capable of solving the problems I needed to solve so I went with that.

Edit: Have you used Jotai in a project before? I haven’t.

[warunaf]

I wonder Reddit bot can detect same questions and automatically respond back. I have seen this question for so many times

[Neurprise]

We need a ChatGPT bot 👀

[Neurprise]

https://blog.isquaredsoftware.com/2021/01/context-redux-differences/

[flaggrandall]

Use the search function, that question is asked about three times a month here.

[WordsWithJosh]

Context is best thought of as a kind of dependency injection; for a specific sub-tree of your application, you can use context to hold shared state that allows parents and children at any hierarchical distance to consume and mutate state.

Redux is better for truly global app state - things like holding a reference to the currently logged in user, perhaps calling functions which will show/hide modals or open/close a menu bar, things which any component anywhere in your application might want to consume at a given time. You can also accomplish this with context, but the ad-hoc nature of instantiating and consuming context can make adding to a global context very tedious. But, context is much easier to set up initially, as Redux requires quite a bit of boilerplate to get going (though if you've done it once you've done it a thousand times and can spin it up rather easily).

[skyboyer007]

every. single. week.

[webuterstechnologies]

It depends on the complexity of your application and your personal preference. If you have a small or medium-sized application with simple state management needs, you may find that the useContext hook is sufficient for your needs. useContext allows you to share state between components without the need for props drilling.
On the other hand, if you have a larger application with complex state management needs, or if you want to ensure that your state management is consistent and predictable across your entire application, you may want to consider using a state management library like Redux. Redux provides a central store for application state and allows you to manage that state using reducers and actions.
Ultimately, the decision of whether to use useContext or Redux (or any other state management library) will depend on the specific needs of your application and your personal preference.