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!
Top comments (22)
I have a personal rule of only trying new stuff on small, low-risk projects. So, considering that you mentioned an already grown project, I wouldn't even give a chance to Recoil and just stick with Redux for the familiarity.
I've never user Recoil so I can't help comparing them but hooks made Redux much better to work with.
Thanks for the reply. The project is larger than I originally intended, but it is a learning project for trying out new things.
In what ways did you find that hooks made Redux better to work with?
If you use the hook, react-redux (called hook-redux) will be comfortable to use.
In otherwise, you can use the Context/Hoc together by combining the redux.
You should what you feel is right. Personally, I would go and read the documentation on Recoil and see how I feel about it. If the documentation is great and I feel like I understand what they're telling me and I'm jiving with it, I would totally go Recoil. But, if I didn't jive or get it, I would stick to redux.
I think the Redux hooks make your code way cleaner than using the connect HOC. Here's an article I wrote comparing Redux hooks to connect HOC and the syntax of it all.
Also, going React context API is another way to go as well. Nothing wrong with that. For larger projects that use global state management, the Redux middleware logger is a beautiful thing in my opinion. If you use the Redux toolkit, it comes built-in with a logger type middleware and has some even fancier things that you can do with it. I prefer Redux over context for all the dev tools and fancy features that you can add to it. I also like the syntax of it all.
These days, I build my back ends with GraphQL and Apollo, so I let Apollo manage all of my state coming from the API. Apollo cache has some amazing features that Redux doesn't have. Like when you update a table and you can update the cache everywhere in your UI by just specifying that you want to refetch a query when the mutation is done. Lot's of great dev tools as well. Apollo does an amazing job at state management in my opinion.
I will definitely check out your article. Thank you for sharing all of your ideas. I especially like "You should do what you feel is right". Sometimes I feel like there is a lot of judgment over the right or best way, when many different options are valid. Thanks for the reminder!
Any time! Everybody has ideas and opinions and while those are super useful to hear and consider when making decisions, at the end of the day, you'll sleep better if you go with your gut. :)
I took the Redux hooks route in the end. So nice to use!
Nice! That's good to hear. Glad it worked out for you. :)
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...
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.
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.
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.
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.
Why not both?
Redux for storing data state (like Users, Posts,...)
Recoil for storing global UI state, or nonpersistent data (like online, typings,...)
Depends on how well you know Redux and how much you care about this project not surviving if Recoil doesn't make it.