DEV Community

loading...

Discussion on: Recoil - Ideal React State Management Library?

Collapse
brianmcbride profile image
Brian McBride

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.