Recoil – A state management library for React
recoiljs.org
Recoil – A state management library for React
1–10 of 83 posts
Re: Recoil – A state management library for React
#2[deleted]
Re: Recoil – A state management library for React
#3I'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 too much on generators for my taste. (The source code is smart but it's also wildly complex.) All of it is castles in the sky for no good reason. You don't need any of that anyway.
Re: Recoil – A state management library for React
#4I'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 functions, you should. That's the approach we try to take for asynchronous processes: just a pure function that you happen to evaluate on some other process. This obviates the need for things like sagas. So I agree with you there I guess.
If you post an example of what you don't think it could handle I will tell you how we would handle it.
Re: Recoil – A state management library for React
#5I'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…
I've never had my bottlenecks end up being because of Redux, but that could just be me.
I'd love to take a look at a larger project using Recoil though, just to get a sense for how it looks with a relatively complex state setup. My first impression is that it would get messy pretty quick, but I've been wrong many times before :)
Also, I'm not trying to shit all over your project, congrats on rethinking state management. Regardless of how I feel about your library, that's still awesome.
Re: Recoil – A state management library for React
#6Earlier 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…
I've never had my bottlenecks end up being because of Redux, but that could just be me. I'd love to take a look at a larger project using Recoil though, just to get a sense for how it looks with a relatively complex state setup. My first impression is that it would get messy pretty quick, but I've been wrong many times before :) Also, I'm not trying to shit all over your project, congrats on rethinking state manageme…
The app in question had thousands of connected components, so that was a huge bottleneck for them. For many apps it doesn't matter.
The app that Recoil was originally extracted from has an extremely complex set of state and interdependent derived processes -- also heavily hooked into and modified by third-party plugins. This type of complexity is exactly what Recoil was designed to handle.
Thanks for your kind words.
Re: Recoil – A state management library for React
#7I'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.
[0] MobX https://mobx.js.org/README.html#introduction [1] MobX State Tree: https://mobx-state-tree.js.org/intro/philosophy
Re: Recoil – A state management library for React
#8Is there any support for changing multiple atoms at once / batch? This is where reducers shine to me - dispatching a single action from the ui in redux that multiple reducers can listen to and use to update their state.
Also is there any support for getting the values of atoms outside of a hook? For example from an async action that is not coupled to the render loop which also wants to know the current value.
Re: Recoil – A state management library for React
#9Sounds a lot like re-frame[1] (which I believe predates Redux), they even call the state "atoms."
Re: Recoil – A state management library for React
#10Earlier quoted context omitted.
I've never had my bottlenecks end up being because of Redux, but that could just be me. I'd love to take a look at a larger project using Recoil though, just to get a sense for how it looks with a relatively complex state setup. My first impression is that it would get messy pretty quick, but I've been wrong many times before :) Also, I'm not trying to shit all over your project, congrats on rethinking state manageme…
The app in question had thousands of connected components, so that was a huge bottleneck for them. For many apps it doesn't matter. The app that Recoil was originally extracted from has an extremely complex set of state and interdependent derived processes -- also heavily hooked into and modified by third-party plugins. This type of complexity is exactly what Recoil was designed to handle. Thanks for your kind words.
That's awesome. Best of luck going forward!