DEV Community

Cover image for Recoil  - Ideal React State Management Library?

Recoil - Ideal React State Management Library?

Alex Zavalii on June 07, 2020

In May 2020, Dave McCabe gave an interesting talk about the new state management library called Recoil. The video clicked immediately with me and i...
Collapse
 
markerikson profile image
Mark Erikson • Edited

Hi, I'm a Redux maintainer. A few quick notes:

  • To my knowledge, Recoil is not currently Concurrent Mode compatible. David McCabe made a couple comments on Reddit about investigating options like the upcoming useMutableSource hook, but I don't have a link to that discussion atm.
  • React-Redux will also eventually be using that useMutableSource hook when it's out, likely in a React-Redux v8 release. This won't make it "fully CM compatible", but it will likely be sufficient to allow React-Redux to work in a CM-configured React app
  • The Redux code splitting recipe you pointed to basically boils down to re-generating the root reducer by calling combineReducers again, and then passing that to store.replaceReducer()
  • I'm currently working on a major set of updates to the Redux core docs, including new tutorials and reorganized content. That said, you mentioned things like "where does my business logic go?", and we specifically already answer questions like that in the Redux FAQ. The new Redux Style Guide page also gives specific guidance on recommended patterns and best practices.
  • Finally, please check out our official Redux Toolkit package, which is specifically designed to simplify most common Redux use cases.

Note that I'm not saying anything negative about Recoil here. While I haven't tried it out, it definitely looks interesting. I'm just saying that you might want to reconsider the list of negatives you listed for Redux :)

Collapse
 
alexandrzavalii profile image
Alex Zavalii

Thank you Mark! I will follow your notes.

Collapse
 
birdtho profile image
Christopher Thomas

Go try it out.

Collapse
 
vacom profile image
Vitor Amaral

Recoil is very simple to use and feels like it is included in the React core. Oficial or not it is made by Facebook I think that gives some proximity to React. Recoil has a lot of potential, let's help it grow. Nice article Alex. Cheers.

Collapse
 
brianmcbride profile image
Brian McBride

Keep in mind that the "React Core" isn't a very complicated and other libraries work just as fine.
I suggest you take a look at Hookstate.js. It is basically the same thing as Recoil, but I'd go as far to say it is even easier to use.

The problem with Facebook koolaid (realize that I still pick React for my front end work, although I am considering Preact these days), is that Facebook engineers are people too. In fact, they are people who passed an interview in Silicon Valley that is known to be sexist, racist, and agest (sadly). What I am getting to is that these tech giants don't have the best of the best, they have the best applicant at the time who passed their biased culture screening.

My point is here, although Recoil has many aspects that I prefer - why didn't Facebook just adopt an existing library? We already have this solution out there. Instead, there is an alpha/beta codebase with less features that the entire community is making hype about. It doesn't mean it will get better development either, as most developers just use libs like redux and rarely bother to actually look at the source to see what it actually does, much less try and contribute to it.

Collapse
 
alexandrzavalii profile image
Alex Zavalii

Thanks Victor!

Collapse
 
thisdotmedia_staff profile image
This Dot Media

Awesome article Alex!

Collapse
 
alexandrzavalii profile image
Alex Zavalii

Thank you!

Collapse
 
thisdotmedia_staff profile image
This Dot Media

Np 😊

Collapse
 
kawashita86 profile image
kawashita86 • Edited

Just as a matter of taste, i love using redux as It allows me to split my presentational layer from the state/remote data action one. Using redux+rx/js further separate those concept having actions behaviour in a different folder from actions and reducers. It's clean, easily testable and on bigger projects i found myself to touch less files than on project where i use hooks or others libraries. Said that recoil Is interesting and i will follow its evolution closely as It brings really interesting concepts for high-performance heavy-duty UI

Collapse
 
brianmcbride profile image
Brian McBride • Edited

I dunno. If this wasn't a library from a Facebook guy, we probably would be ignoring it. I mean, we have similar code out there. Mobx is one (of many).

No offense to Mark Erikson here in this thread - I can't stand Redux. I love the concepts, the boilerpate though... :) In my projects, I tend to use an Observable library (I have my own spin from RxJS, I've used Mobx, and lately the Apollo client a lot)

So when I see Recoil, I don't see a lot of new, just different. I am not sure it is offering a lot new to the landscape other than splitting focus again.

For me, that's the big issue. If you want to follow an observable pattern, use Observables and help improve on the existing foundations. Maybe I am missing something that is so special about this lib, but the only thing I really see is that it's an internal Facebook library and suddenly everyone is wondering if it is going to become the "official" React tool.

Here is something that I like to share with my teams - is ReactJS going to be the last front end tool we will use? There is something that bugs me that we keep pulling things off the shelf that are not View components but only work with React. When I use GraphQL/Apollo, I know that I can take my queries to VueJS or just to pure web components. I can keep my "engine" code reusable across "view" libraries. Even within React, this can sometimes mean easier upgrades too. We already see this with Redux, Mobx, etc... where I can take any of these state engines and drop them into any UI project (including React Native) and go.

Collapse
 
koistya profile image
Konstantin Tarkus • Edited

Taking the basic use case scenario - UI theme switching implemented using React's useState(), useEffect() vs Recoil. The Recoil implementation looks so much smoother:

Implementing UI theme switching (a.k.a. Dark Mode) using Recoil

Collapse
 
antonmelnyk profile image
Anton Melnyk • Edited

API isn't simpler then Redux at all. No devtools, no clean update cycle, logic inside UI layer isn't a good thing and that is main advantage of Redux, which is pure functions that change state and contain all logic.

Recoil seems like just another overhyped state management tool, while good ol' dog Redux is a proven and solid solution with a great ecosystem.

Collapse
 
creotip profile image
Ruslan Elishaev

recoil + redux devtools
github.com/creotip/recoil-gear

Collapse
 
basit_raza profile image
Basit Raza

Redux is also a good choice, as time passes new technologies take the place of old ones i personally feel implementing redux Restructuring of Business logic, but it work as expected. I just read about Recoil it seem interesting and especially it simple, i'm gonna try it soon.

Collapse
 
pavermakov profile image
Pavel Ermakov

Great article!

Does recoil have some sort of a devtools extension?

Collapse
 
alexandrzavalii profile image
Alex Zavalii

Thats a great question. I think there will be one. Just saw this tweet.
twitter.com/jaredpalmer/status/126...

Collapse
 
creotip profile image
Ruslan Elishaev

recoil + redux devtools
github.com/creotip/recoil-gear

Collapse
 
birdtho profile image
Christopher Thomas

Recoil is really cool. Not only is it good for maintaining different chunks of State here and there, but you can also build hooks around it that have the same data and update the same data no matter where you are in the app. You can use the same hook you wrote to refer to the same data in multiple different components because you're basing that hook off of recoil state.

I get some things like lists of tags or videos, etc and store them in hooks using methods to modify or refresh the list, backed by recoil atoms.

Collapse
 
avkonst profile image
Andrey

No, it is not ideal :) It does not solve the problem of frequent deeply nested state updates. And it is not as simple as Hookstate hookstate.js.org (Disclaimer I am an author)

Collapse
 
robvirtuoso profile image
robvirtuoso

Not ideal because it does not try to do everything???

I tried that library of yours, it is not that simple either. It tries to be an all-in-one solution even for things that are already built into the core. And a big no-no is "overriding" useState hook itself. Why would you do that?

Then it goes on changing the construct of setState. And it is even different depending on the type of state (async vs. non-async). In effect, predictability of intent throughout the code becomes low. Again why would you do that???

Collapse
 
avkonst profile image
Andrey
  1. Not ideal because it does not try to do everything???
    No, because it does not solve the problem of frequent and deeply nested state updates, which might be a use case for large datasets

  2. big no-no is "overriding" useState hook itself. Why would you do that?
    It does not override it. It just have got the same name because it does the same (for the case of the local state). If it is no-no, there is an alternative name 'useHookstate' or you can name alias on import or you can use module prefixes.

  3. Why would you use the same name for different types of an argument? Because whatever the argument is, it gives you back the State object, which has got the same functionality regardless if a state variable comes from local variable, global variable, if it is Promise or not. I know for some people in JS it does not make sense, as they prefer to have different function names depending on whether an input argument is declared in a local scope or global, etc.. I disagree with this naming convention / attitude. It is ok to have different opinion.

Collapse
 
thanhlm profile image
Thanh Minh

Great sharing.

I did have some thought on using Recoildin practical dev.to/thanhlm/recoiljs-in-practic...