Recoil – A state management library for React • Hacker News Board

Re: Recoil – A state management library for React

#51

Post by rjknight » Thu, May 14, 2020, 9:15 PM UTC

davidmccabe wrote: post #12

knubie wrote: post #9

Sounds a lot like re-frame[1] (which I believe predates Redux), they even call the state "atoms." [1] https://github.com/Day8/re-frame

The term 'atom' is a clojure-ism, that's where both I and reframe get it from.

Re-frame's atoms are actually Reagent's 'ratoms' ('reactive atoms'). They're built on Clojure atoms, but can reactively prompt a re-render of any component that depends on them when the content of the ratom changes.

Re-frame wraps Reagent, and introduces the concept of "subscriptions". A subscription either returns the content of an atom, or state derived from it, equivalent to Recoil's selectors. Re-frame also introduces the concept of a global application DB, a single atom that contains various pieces of state, such that you can develop your entire app around it.

I haven't tried Recoil, but I'll give it a shot on my next JS project - I tend to use ClojureScript for front-end precisely because I find the Reagent/Reframe approach simpler and more effective than any of the plain JS React approaches (for complex apps, anyway).

Re: Recoil – A state management library for React

#52

Post by nohuhu » Thu, May 14, 2020, 9:27 PM UTC

weeksie wrote: post #3

I'm not seeing how this works with more complex state flows. Doesn't seem much better than useReducer. Frankly, for state management I still haven't found anything that beats Redux on its own without thunks or sagas or any of that bullshit. This is despite doing my level best to see if useReducer on its own would be sufficient. It's not. Thunks are unmaintainable. Sagas are put together with bailing twine and rely to…

One viable alternative for thunks and sagas that I came up with is using async functions and explicitly getting/setting state: https://github.com/riptano/statium#viewcontroller

Still a long list of chores to improve API, tooling, etc but very performant and battle tested.

Re: Recoil – A state management library for React

#53

Post by davidmccabe » Thu, May 14, 2020, 9:44 PM UTC

mmerickel wrote: post #20

davidmccabe wrote: post #11

Earlier quoted context omitted.

If you update multiple atoms within a React batch, they will be updated at the same time, just as with React local state. You don't need to wrap the changes in anything to have them occur together. In other words, this updates both of the atoms together: const [a, setA] = useRecoilState(atomA); const [b, setB] = useRecoilState(atomB); ... onClick={() => { setA(a => a + 1); setB(b => b + 1); }} If the new values of mu…

It seems like something could be written around useRecoilCallback() to watch/get the current value of an atom outside of a React component. Does that sound right?

For a specific set of atoms you could subscribe to them with a component and then use an effect to send the values out. For all atoms you could use useTransactionObservation.

Re: Recoil – A state management library for React

#54

Post by beirut_bootleg » Thu, May 14, 2020, 9:57 PM UTC

tshaddox wrote: post #47

rhacker wrote: post #46

Seems to be roughly the same amount of boilerplate as useContext, so I don't fully understand the separate purpose for it?

Recoil allows you to create atoms and selectors in loops without having to add an entire new Context.Provider component to the root of the React component tree, which would obviously not be viable since the entire tree would need to be torn down each time.

This is the part that completely lost me. Why do you need an additional context for each item? Isn't one context holding all items enough?

Re: Recoil – A state management library for React

#55

Post by mariusandra » Thu, May 14, 2020, 10:26 PM UTC

I'm someone who through sheer coincidence (the right projects at the right time) happened/lucked into developing a React state management solution (https://kea.js.org). I've probably sunk hundreds of hours into this project by now.

5 hours before this HN post I asked for comparisons with different site management libraries on Github here: https://github.com/keajs/kea/issues/106

React state management is indeed a mess, meaning there are so many options to choose from. Unfortunately, even for me, a library author, it's hard to evaluate all of them properly. It would take just too much time and you never know where the real problems in any framework lay before you get neck-deep in code. And then you're too far to switch to another framework anyway.

Someone should really map out this landscape in more depth than just an awesome list. I hope the issue linked above can spark some discussion.

In any case, I personally think Kea is a very good solution for React state management, yet obviously I'm biased. Shrug.

And, to keep it on the topic, Recoil seems very low level and I think you need to invent a lot of things yourself to get a full app out of it. Cool to see people trying stuff though :).

And it's from Facebook so who knows, just by proxy it might become the default "atom" and someone will build molecules out of them...

Re: Recoil – A state management library for React

#56

Post by diffrinse » Thu, May 14, 2020, 11:02 PM UTC

davidmccabe wrote: post #4

weeksie wrote: post #3

I'm not seeing how this works with more complex state flows. Doesn't seem much better than useReducer. Frankly, for state management I still haven't found anything that beats Redux on its own without thunks or sagas or any of that bullshit. This is despite doing my level best to see if useReducer on its own would be sufficient. It's not. Thunks are unmaintainable. Sagas are put together with bailing twine and rely to…

Well, I know that on one tool we saw a 20x or so speedup compared to using Redux. This is because Redux is O(n) in that it has to ask each connected component whether it needs to re-render, whereas we can be O(1). useReducer is equivalent to useState in that it works on a particular component and all of its descendants, rather than being orthogonal to the React tree. I think if you can model something with pure funct…

>Well, I know that on one tool we saw a 20x or so speedup compared to using Redux. This is because Redux is O(n) in that it has to ask each connected component whether it needs to re-render, whereas we can be O(1).

Don't I get the same perf with selectors?

Re: Recoil – A state management library for React

#57

Post by iimblack » Thu, May 14, 2020, 11:22 PM UTC

MoSattler wrote: post #25

weeksie wrote: post #3

I'm not seeing how this works with more complex state flows. Doesn't seem much better than useReducer. Frankly, for state management I still haven't found anything that beats Redux on its own without thunks or sagas or any of that bullshit. This is despite doing my level best to see if useReducer on its own would be sufficient. It's not. Thunks are unmaintainable. Sagas are put together with bailing twine and rely to…

Having worked many years on mid to large scale React apps, I must say: In most cases component state (or useSate) and context works just fine. Why is everyone so eager to add third party state libraries from the getgo? In most projects, Redux doesn't add net value.

Coming from Clojurescript and using libraries like Re-Frame it feels much more natural to me to have a central store for most state. Sure I also use component state but I leave that for very simple cases. It seems like Context could also provide something like this but I'm not sure how it handles re-renders. If one part of my Context state is modified, do all Consumers re-render? Or just the ones that would be affected?

Re: Recoil – A state management library for React

#58

Post by tshaddox » Thu, May 14, 2020, 11:23 PM UTC

beirut_bootleg wrote: post #54

tshaddox wrote: post #47

Earlier quoted context omitted.

Recoil allows you to create atoms and selectors in loops without having to add an entire new Context.Provider component to the root of the React component tree, which would obviously not be viable since the entire tree would need to be torn down each time.

This is the part that completely lost me. Why do you need an additional context for each item? Isn't one context holding all items enough?

If you have a lot of pieces of data in one React context, every component that uses any little piece of that data will re-render whenever any part of the data changes.

Re: Recoil – A state management library for React

#59

Post by cwackerfuss » Fri, May 15, 2020, 1:31 AM UTC

Check out easy-peasy. Ive used plain ol redux, mobx, and xstate, but easy-peasy is the fricken best. It's basically a redux wrapper that combines redux, thunks, reselect, redux logger, immer, and more into a super intuitive interface. The typescript support is super good and interacting with the API feels very modern and hook-driven.

https://github.com/ctrlplusb/easy-peasy

Re: Recoil – A state management library for React

#60

Post by nwienert » Fri, May 15, 2020, 1:39 AM UTC

cwackerfuss wrote: post #59

Check out easy-peasy. Ive used plain ol redux, mobx, and xstate, but easy-peasy is the fricken best. It's basically a redux wrapper that combines redux, thunks, reselect, redux logger, immer, and more into a super intuitive interface. The typescript support is super good and interacting with the API feels very modern and hook-driven. https://github.com/ctrlplusb/easy-peasy

If you want even cooler try overmind:

https://overmindjs.org

But Recoil is slightly different, designed to be “component first” essentially. Not global. It’s how my own personal mobx based library works. But this one likely has concurrent mode baked in.