Live data from Hacker News

Recoil – A state management library for React

recoiljs.org

11–20 of 83 posts

Re: Recoil – A state management library for React

#11

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

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 multiple atoms are interdependent on each others' current values, it's possible to update multiple atoms together using the transactional/updater/function form, but we need to add a nicer interface for doing this. Coming soon! The nicer interface would probably look something like this:

  const update = useTransactionalUpdate([atomA, atomB]);
  ...
  onClick={() => {
    update(([a, b]) => [a + b, b - a]);
  }}
It's then easy to make a hook that provides a reducer-style interface over a set of atoms. But now, unlike with Redux or useReducer, each atom still has its own individual subscriptions!

Re: Recoil – A state management library for React

#13
post #7
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…

> 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. […

MobX State Tree advocate here. We have a VERY complex state that needs to be synced with the server and persisted locally and nothing fulfilled our needs like MST.

Also, sign me up to the Sagas-are-bullshit club.

Re: Recoil – A state management library for React

#14
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.

Re: Recoil – A state management library for React

#15
post #7
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…

> 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. […

I still use mobx for almost everything. Sometimes without React (like a dmx light controller and a midi controller for guitar effects).

Re: Recoil – A state management library for React

#16
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.

Lots of software has "atomic" concepts. Like SQL databases.

Re: Recoil – A state management library for React

#17
post #14

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.

I’m working on a detailed comparison for the docs. Thanks for the feedback!

Re: Recoil – A state management library for React

#18
post #7

Earlier quoted context omitted.

> 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. […

MobX State Tree advocate here. We have a VERY complex state that needs to be synced with the server and persisted locally and nothing fulfilled our needs like MST. Also, sign me up to the Sagas-are-bullshit club.

Mobx itself is insufficient? What does mobx-state-tree provide that mobx does not? The README doesn't convey anything meaningful.

Re: Recoil – A state management library for React

#19
What is it about React that state management is such a such a hassle? This is not the case in other frameworks.

Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_...

Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75...

Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem...

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.

Re: Recoil – A state management library for React

#20

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

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?
Post reply on HN