10 ms·

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 anyt

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      That's awesome. Best of luck going forward!
- city41 6y ago
  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 6y ago
  >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 6y ago
    I could be mistaken but I think that you still have to do a shallow compare on the connected props of every component.
    - diffrinse 6y ago
      Nah, you're completely correct
vosper 6y ago
> 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 https://mobx.js.org/README.html#introduction [1] MobX State Tree: https://mobx-state-tree.js.org/intro/philosophy https://mobx-state-tree.js.org/intro/philosophy
- armandososa 6y ago
  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 6y ago
    Mobx itself is insufficient? What does mobx-state-tree provide that mobx does not? The README doesn't convey anything meaningful.
    - Keats 6y ago
      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.
    - armandososa 6y ago
      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.
- hashkb 6y ago
  I still use mobx for almost everything. Sometimes without React (like a dmx light controller and a midi controller for guitar effects).
MoSattler 6y ago
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.
- weeksie 6y ago
  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.
- iimblack 6y ago
  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 6y ago
    All of them. I’d say that’s the biggest problem recoil is addressing.
madisvain 6y ago
For complex state flows we use Kea JS. https://kea.js.org/ 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.
christophilus 6y ago
Agreed. But Redux loop is nice. Kinda like reframe for JavaScript.
nohuhu 6y ago
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 https://github.com/riptano/statium#viewcontroller Still a long list of chores to improve API, tooling, etc but very performant and battle tested.
- weeksie 6y ago
  If that works with your model of the world that's great. Wouldn't kick it out of bed for farting. For me, the easiest way to handle async and effects in Redux is to write custom middleware for each context/entity. That's what it's for. It makes it possible to have a real message based architecture without hacks and (extra) libraries.
  - nohuhu 6y ago
    > If that works with your model of the world that's great. Wouldn't kick it out of bed for farting. Oh I see, entity naming could also be improved. ;) > For me, the easiest way to handle async and effects in Redux is to write custom middleware for each context/entity. Right, and you still have to deal with Redux to get there. Not a preferred choice for many people. > have a real message based architecture What is a real message based architecture, in your terms? And why is it so important? Genuine question. > without hacks and (extra) libraries. Extra libraries only if you base on Redux and go from there. It's almost as if Redux itself wasn't an extra library...
    - weeksie 6y ago
      Redux is fantastic and it's quite a simple library. The rest is what gets you into trouble. Hardly anybody has a problem with redux until they have to deal with async actions but all the tutorials use thunks or sagas when the correct way to handle that stuff is to write middlware. By real messaging I mean CQRS with event mapping/filtering/normalization.
      - nohuhu 6y ago
darepublic 6y ago
Mind describing why you dislike thunks
- weeksie 6y ago
  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.

davidmccabe 6y ago

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 6y ago
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 6y ago
  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 6y ago
    That's awesome. Best of luck going forward!
city41 6y ago
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 6y ago
>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 6y ago
  I could be mistaken but I think that you still have to do a shallow compare on the connected props of every component.
  - diffrinse 6y ago
    Nah, you're completely correct

vosper 6y ago

> 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 https://mobx.js.org/README.html#introduction [1] MobX State Tree: https://mobx-state-tree.js.org/intro/philosophy https://mobx-state-tree.js.org/intro/philosophy

armandososa 6y ago
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 6y ago
  Mobx itself is insufficient? What does mobx-state-tree provide that mobx does not? The README doesn't convey anything meaningful.
  - Keats 6y ago
    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.
  - armandososa 6y ago
    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.
hashkb 6y ago
I still use mobx for almost everything. Sometimes without React (like a dmx light controller and a midi controller for guitar effects).

MoSattler 6y ago

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.

weeksie 6y ago
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.
iimblack 6y ago
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 6y ago
  All of them. I’d say that’s the biggest problem recoil is addressing.

madisvain 6y ago

For complex state flows we use Kea JS. https://kea.js.org/ 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.

christophilus 6y ago

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

nohuhu 6y ago

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 https://github.com/riptano/statium#viewcontroller Still a long list of chores to improve API, tooling, etc but very performant and battle tested.

weeksie 6y ago
If that works with your model of the world that's great. Wouldn't kick it out of bed for farting. For me, the easiest way to handle async and effects in Redux is to write custom middleware for each context/entity. That's what it's for. It makes it possible to have a real message based architecture without hacks and (extra) libraries.
- nohuhu 6y ago
  > If that works with your model of the world that's great. Wouldn't kick it out of bed for farting. Oh I see, entity naming could also be improved. ;) > For me, the easiest way to handle async and effects in Redux is to write custom middleware for each context/entity. Right, and you still have to deal with Redux to get there. Not a preferred choice for many people. > have a real message based architecture What is a real message based architecture, in your terms? And why is it so important? Genuine question. > without hacks and (extra) libraries. Extra libraries only if you base on Redux and go from there. It's almost as if Redux itself wasn't an extra library...
  - weeksie 6y ago
    Redux is fantastic and it's quite a simple library. The rest is what gets you into trouble. Hardly anybody has a problem with redux until they have to deal with async actions but all the tutorials use thunks or sagas when the correct way to handle that stuff is to write middlware. By real messaging I mean CQRS with event mapping/filtering/normalization.
    - nohuhu 6y ago

darepublic 6y ago

Mind describing why you dislike thunks

weeksie 6y ago
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.