In developing and application, Data management is an important concept used by developers to minimize potential errors by establishing processes an...
For further actions, you may consider blocking this person and/or reporting abuse
If your app is moderately complex and needs a substantial amount of "global" state management, then I'd just go with Redux ... Context is not really THAT much simpler (you'll probably still end up writing the same kind of reducers and actions, etc).
The problem with Context is that it's not that smart about what to re-render, it will often just re-render the whole component tree - Redux does that a lot better, and in the end it's not really harder to use (especially not if you use the great Redux Toolkit, which means you're going to write a LOT less boilerplate).
I haven't used context yet, but as I saw in code samples, it does not look much different from Redux, so you might be right. Redux is a powerful tool above a certain amount of UI complexity. If you had this kind of task to solve, I would just go ahead to learn a bit Redux. If you practice it without trying to memorize the pattern, you will be OK with it. You will realize that your part is just doing the same thing over and over again and it leads a very nice application pattern, which is loosely coupled code. It's easy to test and debug and Redux gives you invaluable tools for this too in the form of browser extension for time-travel debugging. The true difficulties and most of the pattern is hidden away from your eyes and buried in the library itself. If you wanted to touch Redux itself, that would require a very different level of knowledge and skills, but trust me, you couldn't do it better than those, who already done it. It's just better to learn how to use it at the beginning then some day you will be able to understand the inner working of the things inside too. Until that, just rely on the job of those experts, who wrote it for you.
Amen to all that ... and the Redux Toolkit vastly reduces the amount of boilerplate code that you need to write.
Oh nice
Awesome input
Thank you
Thank you too for the article ... and on top of that, Redux can aid in answering the eternal React problem "where the heck do I put my business logic?"
Do I have to jump right into redux or I should use it only when I'm dealing with complex data in state?
I think you can jump into Redux right away, when you are comfortable with basic React. You should be able to use class components, function components, use State and useEffect hooks well. You should know how to do prop drilling as well to pass global state from your root components down to the child components. At this point you should learn some basic terminology and the software pattern, how Redux handles the global state with React. Don't worry about the boilerplate, it's not so bad by these days. You have redux-toolkit and react-redux libraries to make things relatively simple. It's relatively simple, but introducing this complexity only worth for huge UIs, like a Facebook clone for example. Redux docs are very good and written by Mark Ericson. Do his tutorial and you will be able to refractor your app by Redux.
okayy, thanks
I'll take a look at the documentation
Applying Redux is a more powerful tool than simply applying the Context API from React to avoid prop drilling. Redux eliminates the prop drilling, but it does more. In my app for example it beautifully connects Firebase with the React UI. The app was made without Redux first. I used a library, which injected Firebase data into React components directly. Do not do it this way. Most of my components were full of code, handling Firebase. So the back-end handling code was scattered everywhere. This is very bad. Redux let me do that the right way, as Firebase could handle the Redux store separately from the React UI. The link of the app is Fakebook. You can have a look and if you were interested you can see the code on my github. It might be worth a full blog post, but I don't have time for it yet.
Awesome👏👏👏👏
Thank you Alex!
I am not a fan of Redux because of the boilerplating and obfuscating code.
Recoil is looking like a good alternative, is there anyone here that has used it for a production platform?
Recoil works great, it feels like React, much recommended. I've been using it, also in production, for a while now.
Recoil is about "simplicity", like React, like component based programming. Forget Redux, forget Context. Once you use Recoil, you won't go back. imho :o)
If you use Recoil, think atoms, keep the stores as small as possible. Just like: keep your functions, components, files, states and styling (hint: css-in-js, eg. styled-components) : as small as possible. Atomic.
Avoid larger and global scopes as much as possible :o)
Actually replying to @alexerdei73 :)
-- I think one good point is, Redux is a job skill. And actually it should not be. In most cases, the state management does not need to be an (extra) job skill.
-- Recoil (if you keep it simple) is very much like useState. If you need to hold some data for a single file, then you use useState. If you need it for several files, then you use useRecoilState. Otherwise they're kind-of the same, from a certain perspective. You can see it as part of React, just like useState is. It should not be an extra job skill. It is, and should be, just React.
And by the way, I think in many projects, one gets the freedom to choose which tools (eg. hooks) you are going to use.
Now I understand. Recoil is another library to sort out state management for React. Its purpose is like Redux', but according to you and their webpage it's really simple and React like. So it feels like a natural extention of React. It's a very sympatic idea to me. My only problem with it its popularity. Redux is the most popular tool and normally job requirement. Recoil might be the future tool.
Recoil sounds like a more complete solution than React with Redux for example. It must be great for your UI problems. Most of us learns frontend-frameworks to find jobs with these. This might be a questionable motivation, but recoil can be a bad choice with its limited popularity for companies. How it compares for Vue.js for example, which is much less popular than React, but people say similar positive things about it than you say about recoil. Vue is certainly popular enough to find jobs with it. How about recoil?
Thank you for throwing more light on the
Thanks for the post, Inspired by the FLUX patterns and Redux, I recently create this starter template to create Stores using Only React Hooks and Context API.
github.com/gsi-chao/react-hooks-st...
Awesomeeee🥳🥳🥳
Thank you for sharing
Should i use redux for managing multiple modals or using useReducer is enough?
I agree with the author. useReducer might be part of context, which I haven't used yet. Context can handle your modals as these are part of your UI. Redux is advantegous if you need to seemlessly combine your React UI with some other code, because it separates the global state from the UI and it makes it both easily connectable to the UI and other code in a loosely coupled way. If you already use Redux for other reasons, it's great to use it for handling your modals too. Modals only on the other hand do not justify the usage of Redux as these belong to the React UI.
Thank you Alex❤
useReducer is enough if you are not using redux at all in the project.
But if you are already using redux then I suggest you continue with redux for the modals as well
Thanks for great article!!!
I've used redux for many years, but in the previous project, I used react-query including cache.
export const addNewDeviceToList = (key, updated) => {
queryClient.setQueryData(
key,
(old) => {
old.pages[0].data.data.data = [...updated, ...old.pages[0].data.data.data]
return old
})
}
Oh great!
I am glad you like it
I am comfortable with React hooks and context API
Great!
great article! they are indeed complementary stuff and they should be considered in this way
Thanks
Yes sure🥳