[deleted]
Recoil – A state management library for React
61–70 of 83 posts
Re: Recoil – A state management library for React
#62I'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…
> I still haven't found anything that beats Redux on its own without thunks or sagas There was a period in the early days of Redux where MobX [0] (and, perhaps to a lesser extend, MobX State Tree [1]) was the main competitor to Redux that I used to hear about. They both seem to be actively developed, but I don't hear so much about them any more. Have you ever look at either of them? BTW I am 100% with you on Sagas. […
Zustand works for us without much complexity. Its fast and quite easy to use
Re: Recoil – A state management library for React
#63Seems like compared to Redux this would make server-side rendering very challenging. Each atom is a global singleton so I'm not sure how you could render individual requests.
It’s actually designed to make server rendering easy. We’ll add a guide about this eventually. Atoms aren't global singletons: their values are scoped to React trees.
Can you talk about SSR here just a little to give us an idea of how recoil makes it easy?
Re: Recoil – A state management library for React
#64I'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
Re: Recoil – A state management library for React
#65I'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…
Never made any OpenSource lib, but I always had that gut feeling you are talking about here:
"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."
Putting that aside, to me RxJS and especially Cycle.js are "1 abstraction level above" React & friends. (Cycle can be used via React.)
What do you think about these?
Re: Recoil – A state management library for React
#66Can anyone shed some light on if and how this might be used together with xstate ( https://xstate.js.org/ ) which is based on the SCXML spec?
I'll experiment with this.
Re: Recoil – A state management library for React
#67Earlier quoted context omitted.
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.
React has more intelligence built in than that. That's definitely not quite how it works.
Re: Recoil – A state management library for React
#68Seems like compared to Redux this would make server-side rendering very challenging. Each atom is a global singleton so I'm not sure how you could render individual requests.
It’s actually designed to make server rendering easy. We’ll add a guide about this eventually. Atoms aren't global singletons: their values are scoped to React trees.
How exactly does the default state work if that's the case? Is it just up to the user to treat the state as immutable and copy it rather than modifying it?
Re: Recoil – A state management library for React
#69Earlier quoted context omitted.
It’s actually designed to make server rendering easy. We’ll add a guide about this eventually. Atoms aren't global singletons: their values are scoped to React trees.
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.
Re: Recoil – A state management library for React
#70Earlier 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). 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?
I could be mistaken but I think that you still have to do a shallow compare on the connected props of every component.