I'm someone who through sheer coincidence (the right projects at the right time) happened/lucked into developing a React state management solution (<a href="https://kea.js.org" rel="nofollow">https://kea.js.org</a>). I've probably sunk hundreds of hours into this project by now.<p>5 hours before this HN post I asked for comparisons with different site management libraries on Github here: <a href="https://github.com/keajs/kea/issues/106" rel="nofollow">https://github.com/keajs/kea/issues/106</a><p>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.<p>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.<p>In any case, I personally think Kea is a very good solution for React state management, yet obviously I'm biased. Shrug.<p>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 :).<p>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...
I'm not seeing how this works with more complex state flows. Doesn't seem much better than useReducer.<p>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.<p>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.
Here's an awesome video from the library author explaining a bit more about Recoil from today's React Europe live stream if anyone is interested: <a href="https://www.youtube.com/watch?v=_ISAA_Jt9kI" rel="nofollow">https://www.youtube.com/watch?v=_ISAA_Jt9kI</a>.
I'm happy that we are moving away from the redux-like standard. I've tried the API in a dumb example and it looks clean and easy. <a href="https://codesandbox.io/s/three-buttons-example-with-recoil-qiqhf" rel="nofollow">https://codesandbox.io/s/three-buttons-example-with-recoil-q...</a><p>Still don't like the extra naming that you have to think of for every atom/value. Or also the key: prop that you have to define for every atom. It seems redundant for me.<p>And also, as a bundle-phobia guy I am. I think 22kb as extra library is ok but it could be better.<p>Liking a lot Recoil as solution for the three-button problem. I still think that the patch pattern I use with dop is better. In terms of simplicity and extra KB. This is the same example <a href="https://codesandbox.io/s/react-dop-nhj0j?file=/store.js" rel="nofollow">https://codesandbox.io/s/react-dop-nhj0j?file=/store.js</a><p>But I guess I say that because I'm the creator of dop. So I'm so open to critics :)
What is it about React that state management is such a such a hassle? This is not the case in other frameworks.<p>Consider iOS for example. Just add fields in App and you're done:
<a href="https://developer.apple.com/documentation/swift/maintaining_state_in_your_apps" rel="nofollow">https://developer.apple.com/documentation/swift/maintaining_...</a><p>Similarly in ASP.NET:
<a href="https://docs.microsoft.com/en-us/previous-versions/aspnet/75x4ha6s(v%3Dvs.100)" rel="nofollow">https://docs.microsoft.com/en-us/previous-versions/aspnet/75...</a><p>Same in JSP:
<a href="https://javabeginnerstutorial.com/jsp-tutorial/state-management-in-jsp/" rel="nofollow">https://javabeginnerstutorial.com/jsp-tutorial/state-managem...</a><p>But in React it is such a huge issue, and there are multiple competing solutions. There must be something wrong with the design of React that is causing this.
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.<p><a href="https://github.com/ctrlplusb/easy-peasy" rel="nofollow">https://github.com/ctrlplusb/easy-peasy</a>
Sounds a lot like re-frame[1] (which I believe predates Redux), they even call the state "atoms."<p>[1] <a href="https://github.com/Day8/re-frame" rel="nofollow">https://github.com/Day8/re-frame</a>
It would be useful to have a more direct comparison between this and Redux (assuming its not on the website and I missed it). In what use-cases is it preferable, in which would it not be a good fit? In the comments you mention O(1) vs O(n), diving more deeply into that would be helpful as well.
Seems 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.
Is 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.<p>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.
Can anyone shed some light on if and how this might be used together with xstate (<a href="https://xstate.js.org/" rel="nofollow">https://xstate.js.org/</a>) which is based on the SCXML spec?
I wish he would have shown the heavy tree example in 11:55 without the library, seems cute and all but if you don't provide a comparison it's hard to take seriously.