Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recoil – A state management library for React

recoiljs.org

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Recoil – A state management library for React

#71

Post by davidmccabe »

rhacker wrote: post #67
tshaddox wrote: post #58

Earlier quoted context omitted.

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.

React has more intelligence built in than that. That's definitely not quite how it works.

React doesn't have to commit to the DOM if there are no changes, but it still has to render each component and compare the output. Even if the component is memoized, it still has to compare the props. This is fast enough most of the time but it can become a bottleneck in some cases.

Re: Recoil – A state management library for React

#72

Post by weeksie »

darepublic wrote: post #64
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…

Mind describing why you dislike thunks

A few big problems:

* They're a pain in the ass to maintain once you have more than a few async calls

* They are a poor abstraction because async messages often need to do a lot more than just call/response/error. Sometimes you want stuff like backpressure, throttling, etc. and that's a lot messier to model with a thunk

* There's no real need for a library for thunks in the first case, you can mimic the same functionality with the same amount of code by putting async calls in mapDispatch

If I'm working on a small project then shoving async in mapDispatch can work. Most of the time though the best approach is to handle async through a custom middleware pipeline because let's be real–if your project is simple enough that thunks are fine, you probably don't need to be doing it in React.

Re: Recoil – A state management library for React

#73

Post by baddox »

davidmccabe wrote: post #71
rhacker wrote: post #67

Earlier quoted context omitted.

React has more intelligence built in than that. That's definitely not quite how it works.

React doesn't have to commit to the DOM if there are no changes, but it still has to render each component and compare the output. Even if the component is memoized, it still has to compare the props. This is fast enough most of the time but it can become a bottleneck in some cases.

Yes, and component memoization (and PureComponent and shouldComponentUpdate) only prevents re-rendering of the component's descendants. But every component that uses a context value will still re-render every time that context value changes, which could potentially be way too many.

For example, if every Cell component in a big Table component is using the same context value, they will all need to re-render when any cell value changes, regardless of whether the Cell component or some of its descendants are memoized. This is a common pattern in Redux, which solves this problem and will only re-render the Cells which are using cell values which have changed. Recoil would provide the same benefit.

Re: Recoil – A state management library for React

#74

Post by evv »

davidmccabe wrote: post #69
mleonard wrote: post #63

Earlier quoted context omitted.

Can you talk about SSR here just a little to give us an idea of how recoil makes it easy?

Well, I should say "doesn't make it harder". The `RecoilRoot` component accepts a prop called `initializeState` that lets you specify the state of all atoms in the initial render.

Shouldn't the app be allowed to "pull" the required state from the db, rather than having to "push" the initial state into the root of the app? It's not like we should dump the whole database into atoms just in case the app needs to look up one item, right?

I'm mostly curious how this might tie into a server-side DB. Recoil's API provides the fundamentals for a firebase-like persistence system that allows people to skip the complexity of GraphQL, and just use the type system provided by the language (flow/ts/reason).

In any case, congrats on launching such an elegant API. This is one of the nicest reactive systems I've seen for React :-D

Re: Recoil – A state management library for React

#75

Post by diffrinse »

davidmccabe wrote: post #70
diffrinse wrote: post #56

Earlier quoted context omitted.

>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?

I could be mistaken but I think that you still have to do a shallow compare on the connected props of every component.

Nah, you're completely correct

Re: Recoil – A state management library for React

#76

Post by volkandkaya »

mariusandra wrote: post #55

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 me…

Keajs has been amazing I upgraded from 0.28 to 2.0 yesterday and had 1 small issue, had to delete [actions.] from the reducers.

I use to use just Redux and it was such a pain.

I know you have added even more features in v2 that I will need to take advantage of.

If you need to add examples https://versoly.com/ is what I built on top of keajs.

Has about 8 logic stores that have 100s of actions, thunks, reducers and some interesting selectors.

Re: Recoil – A state management library for React

#78

Post by mariusandra »

volkandkaya wrote: post #76
mariusandra wrote: post #55

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 me…

Keajs has been amazing I upgraded from 0.28 to 2.0 yesterday and had 1 small issue, had to delete [actions.] from the reducers. I use to use just Redux and it was such a pain. I know you have added even more features in v2 that I will need to take advantage of. If you need to add examples https://versoly.com/ is what I built on top of keajs. Has about 8 logic stores that have 100s of actions, thunks, reducers and som…

Hey! Thanks for the comment and that's really cool! Your product looks really slick as well!

Would you mind posting in this "who's using kea" issue about versoly as well?

https://github.com/keajs/kea/issues/35

Re: Recoil – A state management library for React

#79

Post by jannotti »

iimblack wrote: post #57
MoSattler wrote: post #25

Earlier quoted context omitted.

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 affect…

All of them. I’d say that’s the biggest problem recoil is addressing.
Post reply on HN