No practical purpose to this question, just tryna connect concepts to get my head around switching from Redux to using useReducer and React contexts - is a Context when used with useReducer` basically a redux store that's only available to components that explicitly import it?
No. Context and Redux are very different tools that solve very different problems.
Context is simply a mechanism to make a single value accessible to a portion of your component tree. It's up to you to write the code that determines what that value is and how it gets updated. This is typically done by storing data in React component state, and creating a value that is passed to a <MyContext.Provider>.
Redux is a separate UI-agnostic state management library that is designed to help you write predictable state update logic and track when, where, why, and how your state has updated over time, with the React-Redux UI bindings layer allowing your React components to interact with that Redux store.
Now, yes, useReducer+useContext do have some similarities to Redux in terms of how your component will interact with them, but they also have very different performance characteristics in terms of when and why your components will re-render.
Please see my extensive post on A (Mostly) Complete Guide to React Rendering Behavior and my additional posts Redux - Not Dead Yet! and React, Redux, and Context Behavior for details on how Redux and Context differ and how
It is not hard to implement the exact logic of react-redux by means of useContext, useReducer and maybe useSelector)
But useContext + useReducer is not a full replacement of Redux.
useReducer is just an alternative to useState.
And useContext comes with https://en.reactjs.org/docs/context.html#caveats
To store multiple values you have to https://en.reactjs.org/docs/context.html#consuming-multiple-contexts
Related
Why would you use the external Redux library over React's own useContext() and useReducer() hooks, with the Higher-Order Component (HOC) pattern?
Installing and importing an additional, large library such as Redux increases the size of your application and consumes more resources. Redux is essentially using the HOC pattern, takes advantage of the JavaScript reducer pattern, and uses a "context" to keep tack of global state.
React HOCs take care the tree hell issue created by context providers, in large apps:
const App = () => {
return (
<Provider1>
<Provider2>
<Provider3>
<Layout>
<Main />
</Layout>
</Provider3>
</Provider2>
</Provider1>
)
}
I've tried to do research on the differences and pros/cons, but haven't come to a conclusion. The only major advantage I see with using Redux is that it has its own browser extension, Redux DevTools, that's helpful for debugging and inspecting global state and HOCs. In your opinion, which is better to use and why? Redux, or React useContext() and useReducer() (with HOCs and useMemo())?
Redux uses context, but not for state value propagation, but just to pass the never-changing store reference down. As such, Redux' context will never cause any rerender. After that, subscriptions to store changes are used with selectors and the useSyncExternalStore hook.
By just using useReducer and useContext, you cannot recreate a performant state management library, as any update to any part of the value passed through the context will rerender all consumers. You can get around that by using many contexts, but ends as soon as you have dynamically added properties or a dynamic number of values you want to propagate performantly.
In short: use a state mgmt library. It doesn't need to be Redux, you can also look into other libraries as MobX, Recoil, XState, Jotai, Zustand, Valtio, HookState or others - but Context is not suited to actually manage state. It's just a mechanism to propagate a single value that rarely changes to a few consumers.
You can read more on this in Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux).
When I've been developing in pure React.js, I was used to store some data into Redux and set some component to listen to changes in Redux (with useSelector (source). But now I am doing facing the same problem but in different technology. In Remix there's no useSelector with Redux. Yes there is possible to use useState but it have to be under one parent compopnent but I don't have this structure. So is there any solution to force component to re-render when some independent state changes?
Thanks
I've tried to call some function to force re-render but that's not 'nice' solution. I've even thinked about storying data into localStorage/cookies but when they change, components doesn't update (I understand why it doesn't force re-render but I've tried it...).
Redux should still work normally even with Remix, as it's just a state manager. It's entirely possible that all you have is a configuration issue with Redux (I personally dislike Redux for how needlessly complex it into use)
You could try React's own Context for storing state that could be used by several components. Other proven state managers are the likes of jotai or zustand.
Even regular state could work because there's always a root component in remix: i.e. root.tsx.
It's hard to understand what you're trying to achieve. Other ways to update various parts of the UI is using nested routes and . You can access parent and child page data with useLoaderData().
I am building a web app where redux is configured and app is fairly large.
Now I want to store some user preferences which will be available as part of an API respopse.
As this data is required to the majority of components I am planning to store data in the context and wrap application using the context.
I have Few questions regarding approach.
Will considering context impact the performance?
As Redux is already configured which internally uses the Context. So should we continue to use redux for user data.
Is it good practice to use Redux and Context together.
Context and Redux are very different tools that solve different problems, with some overlap.
Context is not a "state management" tool. It's a Dependency Injection mechanism, whose only purpose is to make a single value accessible to a nested tree of React components. It's up to you to decide what that value is, and how it's created. Typically, that's done using data from React component state, ie, useState and useReducer. So, you're actually doing all the "state management" yourself - Context just gives you a way to pass it down the tree.
Redux is a library and a pattern for separating your state update logic from the rest of your app, and making it easy to trace when/where/why/how your state has changed. It also gives your whole app the ability to access any piece of state in any component.
In addition, there are some distinct differences between how Context and (React-)Redux pass along updates. Context has some major perf limitations - in particular, any component that consumes a context will be forced to re-render, even if it only cares about part of the context value.
So, yes, you can use them both in the same app, in the same way you can use a hammer and a screwdriver together on the same construction job.
For more details, see my posts:
Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)
React, Redux, and Context Behavior
A (Mostly) Complete Guide to React Rendering Behavior
Will considering context impact the performance?
Since you want to share user preferences that (I guess) do not change often, you could use a React context to share that data.
But performance issues arise when you put multiple different data in one React context that update at different rates. This is because every component that uses the context will be rerendered even if the part of the context it is interessted in did not change. In this case you can split the context and use one context for each part of the data.
Since you want to use the context to share an application state, you should use Redux. In Redux you use selectors to select a part of the application state. This useSelector hook is implemented in a way that it only triggers a rerender of the component if the selected part changes. You can even pass it an equality function if you want to change the way state change is detected.
As Redux is already configured which internally uses the Context. So should we continue to use redux for user data.
I would say: yes, continue with Redux.
Since you already use Redux you should not spread your application state management over different concepts. Put the user settings in the Redux store (like any other application state) and don't handle them special.
Is it good practice to use Redux and Context together
Well, Redux is based on the React context. So if you use Redux it is already a good practice.
If you mean using both for application state management, I think you should go the Redux or the React context way. Mixing them makes it harder to understand where state is managed.
I have been working in React for past 6 months and do not have any experience with Redux yet. Though I have worked with context api and useReducer hook. I need to convert an existing application to react which will have around 100-120 components. My question is about the choice of state management. With the rise of context api and useReducer hook, Can I rely on these two only Or Redux library is still a better choice ? Articles that I found for comparison are from late 2019 so I couldn't decide.
Please guide
Redux is still a much better choice for large scale.
Let's assume you have 10000 global state variables in the global store. And you need to change one.
Context API
It will rerender all of its consumer components which is unnecessary.
Redux
It allows us to selectively rerender components that subscribed to changed values.
So
Context API is good for small scale but not good for large scale.
Fundamentals are still same for context API before and after useReducer.
I think useReducer and contextAPI should be good enough even for large applications if you don't want the time travel that Redux provides out of box, as a by-product of its design.
For large applications, one could have a large state (or multiple reducers combined via combiner) in Redux, and yet avoid re-rendering of components. This is because components are rendered based on parts of state that it depends upon, using the mapStateToProps and mapDispatchToProps magic. With contextAPI and useReducer one designs global state by breaking it up into Providers such that only the sub-tree affected by a particular sub-part of global state is passed that part of global state via its own provider.
Check this out: https://kentcdodds.com/blog/application-state-management-with-react
Recently I had learnt react-redux, I use it to manage state in my website. But I find some interest in react suspense, but seem like suspense is a feature that killing redux. (Maybe) and might cause problem if using together.
For example, if I want to perform async to change state and update the store. Where should I apply the suspense “feature” and redux store update.
I know my question is a bit confusing but I hope you can understand what I said.
Anyone know how to manage state in react SAP if I want to use react suspense? Is only usecontext is usable?
One way you can use suspense and redux together is by using a Suspense library that integrates with redux like Rest Hooks
Suspense and redux are distinct concepts that can be used independently, or together.
Suspense simplifies asynchronous handling, allowing co-location of data dependencies, which makes components independent from their render location, and thus reusable.
Redux enables one centralized store tree, which can be useful when combining information across desperate concepts in a centralized stream.