Recoil – A state management library for React • Hacker News Board

Re: Recoil – A state management library for React

#81

Post by josemaenzo » Sun, May 17, 2020, 8:57 AM UTC

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. https://codesandbox.io/s/three-buttons-example-with-recoil-q...

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.

And also, as a bundle-phobia guy I am. I think 22kb as extra library is ok but it could be better.

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 https://codesandbox.io/s/react-dop-nhj0j?file=/store.js

But I guess I say that because I'm the creator of dop. So I'm so open to critics :)

Re: Recoil – A state management library for React

#82

Post by armandososa » Mon, May 18, 2020, 10:55 PM UTC

topspin wrote: post #18

armandososa wrote: post #13

Earlier quoted context omitted.

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.

Well, you know how MobX itself is very unopinionated? MST is very structured and opinionated. It's also immutable which means you get snapshots of every mutation to the tree which is very useful in almost all cases.

Re: Recoil – A state management library for React

#83

Post by davidmccabe » Tue, May 19, 2020, 3:48 AM UTC

evv wrote: post #74

davidmccabe wrote: post #69

Earlier quoted context omitted.

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

We are planning in the next few weeks an overhauled persistence API. Among other things this will add the ability to provide a callback in `initializeState` rather than a value. However, this doesn't help if you need to do async work to retrieve the value. The way we generally think of SSR is that you get a single render pass and then you're done, no time for async work. So for hitting a database you want something like Relay that statically knows your data dependencies and can do a single request to initialize. It's true that there's some complexity there, but there are also great solutions to really hard problems. Recoil doesn't attempt to address that space.