I'm a new developer working on a React project that has grown from its original scope. I started out just using local state and passing props, but as it has grown it is time to refactor and implement state management. The application involves multiple components with many fetches to external APIs, and displaying the data in various ways across routes.
I have used Redux in the past (but not with React hooks), but I am also considering trying out Recoil.
Should I stick with what I already know (Redux), or take this opportunity to explore a new library (Recoil)?
In your opinion, what are the pros and cons of each?
Thank you in advance for any thoughts or recommended resources!
Latest comments (22)
Although Redux is a long time favorite, Recoil is the new kid on the block but is also I think a specialized approach. Being created by the developers of React, I think it really encapsulates the ideal workflow. Redux is more mature, sure. But recoil is definitely meant for React by React. You couldn't have a better tool. Ultimately, it's up to the developer, I'd make branches to test various implementations and performance, or just to see what feels better.
Hello! I would advise you to try effector - it's really convenient to develop. It does not have a boilerplate as in redux and unnecessary re-renders. It does not need memoization and reselect.
Depends on how well you know Redux and how much you care about this project not surviving if Recoil doesn't make it.
Why not both?
Redux for storing data state (like Users, Posts,...)
Recoil for storing global UI state, or nonpersistent data (like online, typings,...)
Hey, Jesse!
I recommend taking a look at Effector.JS.
This is a reactive state manager library with which you can declare the interaction of events that occur in your web application, as well as convenient to work with side effects (such as data fetching).
It's a good review article:
dev.to/lessmess/why-i-choose-effec...
I recommend you to try out swr.now.sh or React Query, but are state management libs for data fetched from an external source (usually an API). And they come with nice extra features like automatic revalidation, a cache of the data to share it globally, request deduping to avoid duplicated requests.
Hi, I'm a Redux maintainer.
Whichever one you end up settling on for this project, I'd specifically recommend that you take some time to look at our Redux Style Guide docs page, which lists our recommended patterns and best practices, and try out our new Redux Toolkit package, which is our official recommended approach for writing Redux logic. RTK includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.
Finally, as others have mentioned, we're also generally recommending that you should use the React-Redux hooks API as the default UI layer.
Somehow I had missed the Redux Style Guide - what a great collection of tips and practices. Thank you for sharing!
Sure. We've had a few folks say we need to make that more visible somehow. If you've got any suggestions, let me know.
Any particular reason why MobX or Mobx-State-Tree are not on your list?
Will do - looks like a few people are recommending this!
If it's or a substantial project, I would suggest sticking with redux for now. Redux is already established, proven, and reliable. Plus, you already have a wealth of resources backing you up when you need to.
Recoil is promising. After trying it out, I had a much better experience than when I first tried to learn redux. It's much more integrated into the React experience that you'd think it was actually part of React. However, until it matures (if you see the documentation, it still has a lot of unstable API), I would stay away from using it in any huge project with significant stakes.
Cheers,
Adrian
Sound advice. I'm glad to hear you found it promising - my quick exploration led me to believe that too.