Brief Introduction of Recoil.js
Recoil is an experimental state management library for React apps. One point is that it is experimental and very new so it might change and you should not be using it in production apps. Also, it is a state management library for react but not by react by which I mean is that it will help you manage state in your react app but it is not an official state management library released by react. it’s a separate library made by another team in the same large group of people known as Facebook.
Dave McCabe who is a Software Engineer at Facebook gave an interesting talk about Recoil in May 2020, in which he tells us that while working on one of their tools with a complex UI and while implementing the best solution for global state management, they hit a performance and efficiency wall and decided the best way to solve it will be to write their own library.
So now you might be wondering what are some advantages of using recoil over other global state management options like redux and react’s context API.
With component-based approach in React we can manage separate state and logic for each component and can have the ability to re-use them when required. But what if you need some state which needs to be available to multiple components, that is when global state management is needed.
Is Recoil better than redux?
In redux, we have a store, actions, and reducers. Here, the data flow is uni-directional and we can have a decoupled design where data management is separated from the UI. Redux is strict about how code should be organized, which makes it easier for someone with knowledge of Redux to understand the structure of any Redux application and thus generally makes it easier to maintain for larger projects but on the downside, there is a much larger boilerplate code than recoil and because it has a restricted design it also has a greater learning curve than recoil.
Another use-case specific problem can be that as the state is immutable in redux, the reducer updates the state by returning a new state every time which can cause excessive use of memory for larger data but in recoil, we can create multiple Atom independent of each other where you can store your state and can make it accessible around the application.
and currently, both redux and recoil don't have the support for react’s experimental concurrent mode. Recoil is built on React primitives, it is using react state under the hood. Recoil is planning to achieve compatibility with concurrent mode with the use of useMutableSource hook in the future, similarly, React-Redux will also eventually be using that useMutableSource hook, which might not make it fully Concurrent mode compatible, but it will likely be sufficient to allow React-Redux to work in a Concurrent mode configured React app.
Is Recoil better than context API?
Context provides a way to pass data through the component tree without having to pass props down manually at every level. As opposed to Redux, it is good to be used for low-frequency updates, such as theme or locale.
Context lets you store only one single value per Provider. If you have a larger state and store that whole state in one Provider what will happen is whenever the value changes for that Provider all the components which are consuming that value will render again even if it was using a part of that state which didn't even change so when you have a larger state you can split the state into multiple meaningful providers and whenever any specific Provider gets a new value, only the components that consume for that specific provider’s value will be rendered again with the updated value. but sometimes this leads to Provider’s hell as below
But having multiple providers is also not a problem but consider if you have created an app where users can dynamically add or remove items, and each item should have its own context Provider for isolation or for performance reasons. Introducing another item would require placing another Context Provider at the top of the tree, which would cause the whole tree to unmount and mount again which will have performance issues. On the other hand in recoil, we can create dynamic global states, by using atomFamily and selectorFamily.
Context API introduces coupling between the root of the tree and leaves of the tree which makes it harder to code split, suppose the leaves are coming from a plugin or a library, you will have to know what plugins or respective library you gonna need all the way at the top of the tree, it would be much easier if two leaves can share data without involving ancestor at all which is where recoil is good.
For your mental model think of recoil as two component have reference to each other so if you call a state change on one it will sneak over and call state change on the second if they are using the same Atom, due to which the semantics of batching, scheduling all works same as react local state but it's shared.
So to summarise Recoil gives us
- flexible shared state: ability to have different things in sync in different parts of the react tree in a way that is really performant.
- Derived Data and queries: ability to compute things based on changes in state efficiently and robustly.
- App wide state observations: Time travel debugging, undo support, persistence, logging ability to observe what is happening.
Recoil is really an interesting solution that can tackle fast granular updates in a deep tree, which is most useful in high-performance heavy-duty UI with lots of direct manipulation (e.g. graphical editors).
I believe that while developing don’t use something fancy until u realize you have a use case for it. if react state solves your problem use it, if there is a use case for redux then use redux and If there is a use case for recoil use recoil.
