I find the context api and useReducer a much nicer way of state management but some people are saying to use redux toolkit so can anyone explain what it is and how it is superior to the aforementioned context api and userReducer hook??
React Context + useReducer is a very simplified version of Redux.
They both can provide a clean action => reducer => update state flow that is held globally in your application. The key difference is Redux comes with a lot more tools that you would have to rewrite if you decided to go the route of Context + useReducer.
The main thing being, popular middleware libraries!
Redux has access to libraries such as redux-saga and redux-thunk that allow you to do asynchronous actions in a clean and manageable way.
Also you miss out on Redux Devtools, a very useful chrome extension for debugging state management in Chrome Devtools.
Basically, it's up to the application's complexity to decide which you use.
I hope this helped a bit.
Related
Which technique is better for state management in react app?
Actually I want to create a big app where I've to manage my state which technique is optimal for state management context, Redux or react custom hook?
I am personally more inclined towards Redux. But if you are a beginner trying to learn Redux you might have some hard time until you understand it. Once you get it you will also like it. Rather than building your own custom hook, It's better to use Redux as if anything goes wrong/you are struck with something, you have community to support and You can also dispatch async calls using some middleware libs like redux-thunk, etc. You can use Redux with forms as well. I guess if you end building your custom hooks you might end up wasting time, taking care of all these.
Of course, it is better to go ahead with Redux, because it is easier to handle large applications with Redux. It has only a single store, which is basically a javascript object. You can divide the store into many pieces, each piece will be for a particular part of the application. All these pieces will be joined together using the combineReducers function provided by redux.
React is a state management library and with the release of React hooks and massive improvements to React context this method of state management has been drastically simplified.
I think in 99% of the situations we do not need redux and add one layer of complexity to project.
For big scale app maybe redux is better choice. but if you choose React for state management you need good information about some concepts and this concepts is:
Local state vs global state(some component needs local state and putting all of their state in global state leads to a lot of problems)
react context and prop drilling problem and How to use React Context effectively
react hooks especially useReducer and useContext
immutable state
You would always need to ask yourself the question: Do i need an additional library?
Redux is on its decline in popularity, due to improvements on Reacts native state management. There is a reason for that!
If you want to work for a company thats not brand new, there is a chance you have to use redux. I was fortunate enough to convince my team to use our own state management library build only with React.useState under the hood.
If your application state logic is quite simple, meaning: states are mostly local, shared state are mostly between parent-child relationship and different states are not heavily depending on each other, then I recommend only using React useState and useReducer (in case you like to use reducers).
Once your application state is getting complicated, you need to have some sort extra stuff of global state management.
The most important thing you need to know about React.useState is, that the returned setState function is your connection to that components state. Lets assume we can take that function out of the component and use it somewhere else. This way you have a function to update your state from outside of your component.
export let exportedStateSetter;
const Component = () => {
const [state, setState] = useState();
useEffect(() => {
exportedStateSetter = setState;
return () => exportedStateSetter = undefined;
});
return <div>{state}</div>
};
In the example above, you can now import the exportedStateSetter and use it somewhere else to update the state of this Component.
!This is not a best pracitce example, this is a simple visualization.
When you think very critically about this, you will realize that now you know how to set a components state from outside of a component, you know how to set states globally.
I stringly recommend using this approach to either build your own global state library or use some that i have created based on what i explained:
npm install --save react-global-state-hook // simple
npm install --save rx-global // complex
To wrap it up: Dont use Redux, if not required by a job. You can always use Redux conventions, by seperating state into stores, update state with a reducer and actions that interact with the state. For that you can use native React state management, if not only React.useState when used properly. React provides you with everything you need and everything you need to build yourself.
I had the best developer experiences with my own libraries that evolved over time. It forces you to understand state management in general and the framework you are using.
Im open for any feedback on the 2 libraries and if you have any questions regarding state, please feel free to keep posting.
So most of my projects are simple enough that Redux has been total overkill (even though it's worked really well always) - I am going to use Context API on a new project (it will easily do the job, and it's way easier to explain to other devs and get them going on) - Redux has Thunk to handle async actions. I think I understand things well enough to reason that async actions will not be a problem for Context API - Redux Thunk doesn't actually add async functionality to Redux - it simply makes the syntax more palatable. So my reasoning says that Context API will be able to handle any async actions as long as I write code to correctly deal with them. Is this right, or do I need to stick to Redux with Thunk if I want to handle async actions effectively?
I had similar question myself and came across this article that talks about a major difference between Redux and the Context API:
From https://www.academind.com/learn/react/redux-vs-context-api/
The Context API (currently) is not built for high-frequency updates (quote of Sebastian Markbage, React Team), it’s not optimized for that. The react-redux people ran into this problem when they tried to switch to React Context internally in their package.
My personal summary is that new context is ready to be used for low
frequency unlikely updates (like locale/theme). It’s also good to use
it in the same way as old context was used. I.e. for static values and
then propagate updates through subscriptions. It’s not ready to be
used as a replacement for all Flux-like state propagation. ---
Sebastian Markbage
So for the moment, it seems like you might want to look into using React Context for low-frequency updates (e.g. theme changes, user authentication) but not use it for the general state management of your application.
Hope this helps.
React 16.7 has State Hook,so I do not need react-redux anymore,is that right?
To my understanding so far, Hook API is still not fully compatible with redux, and supporting for redux is under development. There is a thread in Github for the implementation of useRedux method.
Meanwhile, I think react-redux is still a better choice at the moment, since its API is already optimised for React app's performance. Implementing your own comparing function for re-rendering logic based on updates of redux store's data is too much for small & medium size projects.
For global state still the react-redux is recommended way.
Use react-redux for disconnected components where need to access share state(global state).
Use react state for form-like components(local state)
I know that there is so many answers in this question.
Anyone explain to me how Redux help your React JS Application more flexible when you are creating a Front End Web Apps.
Thank you in Advance.
From Redux documentation:
From the very beginning, we need to stress that Redux has no relation
to React. You can write Redux apps with React, Angular, Ember, jQuery,
or vanilla JavaScript.
That said, Redux works especially well with libraries like React and
Deku because they let you describe UI as a function of state, and
Redux emits state updates in response to actions.
It's a state management library with a huge ecosystem which lets you more easily set the state for your components across whole application, manage side-effects and many more.
I recommend redux author course about redux. At later part of the course, he explains how to use it with React.
Redux is used to manage the state of the component and it supports single state management system, where as flux is a multiple state management system.
Redux uses dispatchers to dispatch the payload(data) via reducers.
Is Redux still relavant when using Apollo?
I have recently been diving into Apollo 2, and have seen a notable post stating that they have removed a lot of redux code in favor of Apollo.
https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a
I know that Apollo 1 used redux under the hood, but that has been deprecated in v2, and several sources have pointed to using apollo-link-state and Apollo Cache as a replacement.
The Apollo Dev tools are super useful but I find myself often wishing to use Redux Dev Tool to be able to see the application global state, use time-travelling and see all that actions called.
It may be that im still getting use to Apollo, but I wanted to know is there still an advantage to using Redux with Apollo?
Update
I have found someone who has build a simple application using Apollo 2, which clearly makes me think think that Redux is completely unnecessary in Apollo.
https://hptechblogs.com/central-state-management-in-apollo-using-apollo-link-state/
State management in a react application is a multi-dimensional issue. It involves coordinating/analyzing states of different components in your screen and managing asynchronous state + data flow (http, persistance, etc.). Apollo started out by only addressing the asynchronous state management. It abstracted away graphql http calls as internals of components. Redux started out on the other side by managing local synchronous state. Today though both solutions are able to provide a local and remote data state management implementation and could be considered interchangable.
The biggest difference between both solutions is the underlying state transition philosophy. Apollo requires less boiler plate by going against the idea of having pure state transitions. On the other hand, Redux follows more of a strict approach to ensuring stat transition occurs in a pure way. I personally like using Redux with GraphQl since Im a big fan of having my state being a result of a series of actions. It keeps things predicatable while still enabling GraphQl to be used by an async handling middleware like redux-saga or things of the sort.
TLDR: Apollo is simpler as it allows the library to do a lot of the async work but comes at the cost of not using Redux's awesome action command pattern.
I have found someone who has build a simple application using Apollo 2, which clearly makes me think think that Redux is completely unnecessary in Apollo.
https://hptechblogs.com/central-state-management-in-apollo-using-apollo-link-state/
Apollo GraphQL Client can also work with any REST endpoint https://www.apollographql.com/docs/link/links/rest.html. So you don't even need to change the backend...