Before we walk down to theory, We have Repo out with a demo to show the difference between Recoil & Redux. Also, try running the application to see how new features from Recoil makes a difference.
Performance
Recoil subscriptions are on atom/selector updaters, while Redux is on all actions. So if you have N connected component and dispatch an action that should trigger only one component, even if re-render is stopped by useSelector optimization, redux have to execute N subscription callbacks.
Boilerplate code
You could have less than 5x boilerplate with redux, with many wrappers like RTK or redux-query, but even that you will write less code more powerful with recoil. Set(atom, value), Execute Task is much more easy concepts to manage with, than dispatch, actions, reducers, sagas, etc…
I have created a repo to highlight the difference.
Learning curve
High in Redux as Recoil follows the React principles so Recoil has less learning curve involved, In Redux we need to understand the flow for updating state with the help of actions and need to get hang of end to end flow as well as shown in the below diagram.
Async Support
In Redux we can connect use redux-saga to achieve async support to separate the API calling mechanism within React application.
In Recoil, we have a mechanism to handle async internally where I found it really interesting with the help of selectors
You can checkout with repo for more understanding.
State
We have a global store in Redux, Everything is stored in store which is really performant whereas Recoil provides an individually subscribe/changeable unit of state with atoms and selectors. Recoil states using 10,000 atoms are also very performant.
source: https://recoiljs.org/blog#scaling-to-large-numbers-of-atoms
Middleware
Redux comes with the support of middleware such as redux-thunk/redux-saga. Which separates the API calling mechanism from application easily testable. Recoil internally handles many things for handling loading state while calling API which is used for showing loader till data is fetching. Also for async operation, we can use selectors which are very robust.
Memorized
Caching can be handled using re-select library for Redux state, Reselect cache the output against the input provided to it. If we have a sum function and we are calling it with parameters 3, 5 it will return 8, Next time if you call the same function with 3, 5 it will not re-compute the value it will return the cached value, Which is handled internally in Recoil. You don’t need any third-party library for this.
Within our repo when we try to call API from async selector, It will call only first mounted component later on it will return the cached value.
Conclusion
Recoil is still in an experimental phase and we can track it here. Whereas Redux is a much stable state. Whereas considering the experimental phase is still used by many developers as well as by Facebook in production, I think it can replace. What do you think? Please share your thoughts via comments.
Useful Links:
1. Repository
2. Recoil Setup
3. Recoil Track releases
Summary
In this article, we have discussed many advantages of Recoil over Redux. While Recoil is being used extensively by Meta and lots of developers, its ‘Experimental’ state makes many developers nervous to write off Redux just yet, which is indeed much more stable.
Hi,
Thanks for this comparison.
I think there’s a mistake in the table. The column values for Async and Memoized rows should be swapped.
And async logic in Redux can also be done via redux-thunk not only redux-saga.
Thanks Dima for pointing this out. Will correct I think something went wrong while converting table to image.
it seems like values of each ‘bolierplate code’ and ‘async’ row in the very first table are switched.
Thanks bb-in-hoodie for pointing this out. Will correct I think something went wrong while converting table to image.