[weeksie]

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

[davidmccabe]

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.

[weeksie]

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.

[davidmccabe]

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.

[weeksie]

That's awesome. Best of luck going forward!

[city41]

You can hoist useReducer out to context and end up with essentially a very lightweight redux. I’ve had some success with that in smaller apps. For something large or long term I’d probably avoid that approach though.

[diffrinse]

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

[davidmccabe]

I could be mistaken but I think that you still have to do a shallow compare on the connected props of every component.

[diffrinse]

Nah, you're completely correct

[vosper]

> 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

[tekkk]

At least in the company where I worked in, everyone agreed that Mobx was the better option between it and Redux. It's so much more intuitive to grasp and using simple functions and objects much easier, than having to grok weird async-flows and cumbersome action-generators and whatnot.

Only problem so far, or inconvenience maybe, is the sometimes complicated ways you come to intertwine stores which have access to different parts of the fetched API data. So if you need data Y stored in store X inside store Z, you have to inject store X as dependency to store Z. Getting too carried way with these injections can make your whole state quite messy. Or loading too much logic into one store.

Probably that's just an architectural issue, that can be remedied with enough thought put into it, but I haven't at least found a clear pattern that would make it simple to decide when to break up stores, or how to refactor them.

Also you have be aware of the complexities of observables which are a bit magical. Knowing when observables don't update and how to observe in general is very much a necessity (unless you want interesting bugs).

I have been curious to try out Mobx State Tree but alas haven't had time.

[armandososa]

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.

[topspin]

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

[armandososa]

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.

[Keats]

Mobx itself is fine for most usecases I think. I've used it on 4-5 projects now and it's been working very well in each.

[artminister]

Zustand works for us without much complexity. Its fast and quite easy to use

https://github.com/react-spring/zustand/

[hashkb]

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

[MoSattler]

Having worked many years on mid to large scale React apps, I must say: In most cases component state (or useSate) and context works just fine.

Why is everyone so eager to add third party state libraries from the getgo? In most projects, Redux doesn't add net value.

[iimblack]

Coming from Clojurescript and using libraries like Re-Frame it feels much more natural to me to have a central store for most state. Sure I also use component state but I leave that for very simple cases. It seems like Context could also provide something like this but I'm not sure how it handles re-renders. If one part of my Context state is modified, do all Consumers re-render? Or just the ones that would be affected?

[jannotti]

All of them. I’d say that’s the biggest problem recoil is addressing.

[weeksie]

I've been working with React since 2014 and I've never had a good experience with an app that relied entirely on component state. To each their own, perhaps you've discovered something I haven't.

For me, Redux works very well with how I think about control flow. That said, my brain has been ruined by a youth misspent in fp land, so my preferences should be taken with a liberal application of salt.

[madisvain]

For complex state flows we use Kea JS. https://kea.js.org/

The library has been around for a while and reduces a lot of boilerplate.

Is also used by some quite big names.

[nohuhu]

One viable alternative for thunks and sagas that I came up with is using async functions and explicitly getting/setting state: https://github.com/riptano/statium#viewcontroller

Still a long list of chores to improve API, tooling, etc but very performant and battle tested.

[christophilus]

Agreed. But Redux loop is nice. Kinda like reframe for JavaScript.

[darepublic]

Mind describing why you dislike thunks

[weeksie]

A few big problems:

* They're a pain in the ass to maintain once you have more than a few async calls

* They are a poor abstraction because async messages often need to do a lot more than just call/response/error. Sometimes you want stuff like backpressure, throttling, etc. and that's a lot messier to model with a thunk

* There's no real need for a library for thunks in the first case, you can mimic the same functionality with the same amount of code by putting async calls in mapDispatch

If I'm working on a small project then shoving async in mapDispatch can work. Most of the time though the best approach is to handle async through a custom middleware pipeline because let's be real–if your project is simple enough that thunks are fine, you probably don't need to be doing it in React.