I built an app at work using Recoil, and I have a strong opinion on why you should not use it.
I see that the library is about 2x as popular on npm as redux-observable, which is the library I'm interested in replacing Recoil with. This is why I feel I should write something.
Reason 1: Recoil wraps async functions with atoms and/or selectors. These objects trigger the function immediately. Because your atoms and selectors are defined in the root scope, they will trigger their network requests on startup, but in no particular order. This inherently creates race conditions, because you don't know which one will finish first. As your application grows in scale, you will eventually create race condition bugs which are hard to solve because your data isn't loading in a defined order.
Reason 2: Your data isn't auditable (like in Redux). You can't debug problems by looking at the data, or by seeing the order in which it was loaded.
Reason 3: Recoil doesn't prescribe an architecture. Assume you have some component which is holding state in Recoil. Now you want to build an app around this component. Your app will fetch some data, then push that data to the shared state in your component. So you wrap your fetching function in a Recoil atom, because why wouldn't you? Now you've received your data, so you then push that data into the other Recoil atom, the one for your shared component, and OH NO! Recoil doesn't do that. Why not? Because reasons. Does Recoil have a solution for how this architecture should work? No.
Reason 4: I've lost significant time spent tinkering on problems, trying various approaches, just trying to find one that would work, only to find that the best solution was to remove Recoil and use React's native hooks. Whereas, with libraries like Redux and RxJS, chances are you can find examples of the right way to make something work. This means you're going to be much more likely to hit your estimates using Redux and RxJS than you are with Recoil.
If the author of Recoil can solve the above issues, I'd be happy to update my opinion on it. As it stands now, I think it's important that developers steer clear.
Top comments (0)