I’ve seen some folks misunderstand Recoil and spread that confusion so I feel the need to clarify.
Recoil is not in any way an “official” state management library for React. And neither is (or ever was) Redux.
The only “official” state library for React is React itself.
Recoil is not in any way an “official” state management library for React. And neither is (or ever was) Redux.
The only “official” state library for React is React itself.
Redux works well for some teams, and they’re welcome to use it. Recoil works well for other teams, and they’re also welcome to use it. React alone also works well for some teams, and they’re welcome to use it.
Over time, React has taken some ideas from projects that aim to complement it. For example, the useReducer Hook is inspired by the parts of Redux API that we think work well.
It is quite possible that some ideas or techniques from Recoil might eventually make it into React too.
It is quite possible that some ideas or techniques from Recoil might eventually make it into React too.
If you see “$COMPANY releases a $LIBRARY” as a grand announcement that you should rewrite your code, your picture of how companies and libraries work is messed up.
The reality is that some people built something, found it useful, and shared it with the world. No grand narrative.
The reality is that some people built something, found it useful, and shared it with the world. No grand narrative.
We do talk to each other. React team has contacts with Redux team (btw Redux isn’t a Facebook project). React team is also in touch with the folks who work on Recoil. We discuss ideas and limitations sometimes. That’s really all there is to it.
What does “official” mean? I think I take it as “recommended without reservations”. But if something is 100% recommended, why not make it a part of React itself? This is why we don’t really have “recommended” libraries that solve the same tasks as React (e.g. state + rendering).
Generally, these libraries bring tradeoffs with them. E.g. maybe they give you something that React doesn’t, but at the expense of some other React features. If we find an approach that doesn’t have downsides, ideally we would build it into React itself.
React team is fairly small and tends to focus on one thing at a time. For the last few years, our focus has been scaling huge React applications. That involves different approaches to loading code and data, revealing loading states, hydration and interaction responsiveness.
This means we haven’t focused as closely on other aspects, such as animations or fast deep updates (e.g. the ones a graphical editor might run into). It’s great to have folks in the ecosystem, both inside and outside of FB, experiment with solutions to those problems.
The great thing about it is that by the time we can focus on those problems, there is so much prior art to take inspiration from. This is very helpful.
