4 ms·

I think it's because redux is quite painful to use with very modern apps. Most of the time you need something like `redux-saga` or `redux-thunk` to deal with as

I think it's because redux is quite painful to use with very modern apps. Most of the time you need something like `redux-saga` or `redux-thunk` to deal with async side effects. I'm not sure which is the most popular today, but sagas are based on generators and trying to use those with typescript is very very painful and the underlying issue [1] is marked as a design limitation in TS itself. In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded. 1. https://github.com/microsoft/TypeScript/issues/32523 https://github.com/microsoft/TypeScript/issues/32523

doodlesdev 4y ago
In my experience the experience with Redux Toolkit is awesome, it's essentially an opinionated way to use Redux for modern web applications and I believe they really hit the mark when it comes to reducing boilerplate and the need for extra deps. Although I'm still not a big fan and prefer to use built-in tools of React to manage state when possible (now that we have Context, Suspense, etc.)
geraldwhen 4y ago
You need redux saga because api interactions can be complex. I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display. But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy. Oh, and product now wants to make sure we capture some random third party tracking event in between specific state changes. The ui MUST NOT change until the tracking call succeeds. This and more is trivial in redux saga, and you can write tests around it.
- acemarke 4y ago
  For the record, we actually have recommended _against_ using sagas in most cases for a long time now, and especially for data fetching. Today, our recommendations are: - Data fetching: default to using RTK Query, fall back to thunks if needed - Responding to actions or state changes: use the new RTK "listener" middleware as the main approach See my recent talk "The Evolution of Redux Async Logic" for details: - https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/ https://blog.isquaredsoftware.com/2022/05/presentations-evol... as well as my recent presentation going through "Modern Redux with Redux Toolkit": - https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode...
  - aidos 4y ago
    Oh my. What is this ecosystem where the maintainers are downvoted for explaining the current recommendations for those using their library?
  - cageface 4y ago
    I was called in to rescue a redux-saga based project that had gone badly off the rails. It was one of the worst codebases I've ever had to work with in many years of coding. Stack traces were useless and debugging with anything higher level than log statements was impossible.
    - dboreham 4y ago
      Apparently you don't need to debug if you're a good programmer. This explains why many modern tech stacks (JS, Scala, Kotlin, ...) have a horrible debugging experience.
  - geraldwhen 4y ago
    We specifically moved off thunks because the capricious whims of changing network calls with logic to support it is so much easier in redux saga. Stuff just works. You can handle every edge case. And now there are multiple deployed production apps with real users, so it’s almost certainly never going to be replaced. The cost would be enormous.
    - acemarke 4y ago
      Yeah, I'm not questioning whether you _can_ do things with sagas, and there's definitely cases where their capabilities are valuable. But as I put it in my "Evolution" talk: "Sagas are like a chainsaw. Really powerful, and really dangerous. If you actually _need_ that power, great! But most of the time you don't actually _need_ to use a chainsaw on a daily basis." As the sibling comment said, a lot of times sagas really do end up as spaghetti code, largely because they are so event-driven, and with all the use of generator functions that can make debugging hard. (Ironically, the original Flux Architecture was created to _avoid_ the problems of Backbone-style event triggers causing events to ricochet around the app without a way to understand how things would update in response, and sagas can end up recreating that problem with Redux apps.)
- weeksie 4y ago
  Saga is so heavy and overly complex and you don't really get much out of it if you understand how middleware works. There's really no reason to add a huge dependency to your project. You can do all of that pretty easily with a vanilla redux.
kitten_mittens_ 4y ago
arcanis has a PR to patch up the issue that's sat for a year plus now. https://github.com/microsoft/TypeScript/issues/43632 https://github.com/microsoft/TypeScript/issues/43632 > In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded. In the decade old application we use redux saga in at work, a large portion of our 7MB minified/gzipped main chunk is redux handlers. It'd be nice if there was a relatively simple way to not synchronously load all the reducers up front.
- acemarke 4y ago
  We have docs on code splitting reducers and other Redux logic here: - https://redux.js.org/usage/code-splitting https://redux.js.org/usage/code-splitting There have been some different community packages for helping with that process, but some of them seem to have become outdated (only worked with React-Redux v5, etc). I did see a new one at https://github.com/fostyfost/redux-eggs https://github.com/fostyfost/redux-eggs that seemed like it had potential, but I haven't had a chance to try any of them myself. I also once saw someone play around with the idea of using React's still-not-technically-final Suspense support to help ensure that a lazy-loaded component that relies on a code-split reducer doesn't actually get rendered until that reducer's state is available. Don't have the link handy atm, but if someone wants it ping me and I can go figure out where that was described. Also, the new RTK "listener" middleware was specifically designed to replace almost all saga usages, and you can dynamically add more listeners at runtime via dispatch an `addListener()` action: - https://redux-toolkit.js.org/api/createListenerMiddleware https://redux-toolkit.js.org/api/createListenerMiddleware - https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/ https://blog.isquaredsoftware.com/2022/05/presentations-evol...
weeksie 4y ago
You don't need _any_ of that. You can use vanilla redux and put your asynchronous code in middleware.
- Rumudiez 4y ago
  More of this. Middleware is simpler to grok than reducers and provides a clean, universal solution to async. You don’t need sagas, just dispatch events at meaningful points in time, like when a request is initiated and then another action when it completes. Pretty sure Dan Abramov taught this approach years ago in an egghead tutorial, if it takes hearing it from the horse’s mouth to get you to consider not just throwing more libraries at it

doodlesdev 4y ago

In my experience the experience with Redux Toolkit is awesome, it's essentially an opinionated way to use Redux for modern web applications and I believe they really hit the mark when it comes to reducing boilerplate and the need for extra deps. Although I'm still not a big fan and prefer to use built-in tools of React to manage state when possible (now that we have Context, Suspense, etc.)

geraldwhen 4y ago

You need redux saga because api interactions can be complex. I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display. But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy. Oh, and product now wants to make sure we capture some random third party tracking event in between specific state changes. The ui MUST NOT change until the tracking call succeeds. This and more is trivial in redux saga, and you can write tests around it.

acemarke 4y ago
For the record, we actually have recommended _against_ using sagas in most cases for a long time now, and especially for data fetching. Today, our recommendations are: - Data fetching: default to using RTK Query, fall back to thunks if needed - Responding to actions or state changes: use the new RTK "listener" middleware as the main approach See my recent talk "The Evolution of Redux Async Logic" for details: - https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/ https://blog.isquaredsoftware.com/2022/05/presentations-evol... as well as my recent presentation going through "Modern Redux with Redux Toolkit": - https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode...
- aidos 4y ago
  Oh my. What is this ecosystem where the maintainers are downvoted for explaining the current recommendations for those using their library?
- cageface 4y ago
  I was called in to rescue a redux-saga based project that had gone badly off the rails. It was one of the worst codebases I've ever had to work with in many years of coding. Stack traces were useless and debugging with anything higher level than log statements was impossible.
  - dboreham 4y ago
    Apparently you don't need to debug if you're a good programmer. This explains why many modern tech stacks (JS, Scala, Kotlin, ...) have a horrible debugging experience.
- geraldwhen 4y ago
  We specifically moved off thunks because the capricious whims of changing network calls with logic to support it is so much easier in redux saga. Stuff just works. You can handle every edge case. And now there are multiple deployed production apps with real users, so it’s almost certainly never going to be replaced. The cost would be enormous.
  - acemarke 4y ago
    Yeah, I'm not questioning whether you _can_ do things with sagas, and there's definitely cases where their capabilities are valuable. But as I put it in my "Evolution" talk: "Sagas are like a chainsaw. Really powerful, and really dangerous. If you actually _need_ that power, great! But most of the time you don't actually _need_ to use a chainsaw on a daily basis." As the sibling comment said, a lot of times sagas really do end up as spaghetti code, largely because they are so event-driven, and with all the use of generator functions that can make debugging hard. (Ironically, the original Flux Architecture was created to _avoid_ the problems of Backbone-style event triggers causing events to ricochet around the app without a way to understand how things would update in response, and sagas can end up recreating that problem with Redux apps.)
weeksie 4y ago
Saga is so heavy and overly complex and you don't really get much out of it if you understand how middleware works. There's really no reason to add a huge dependency to your project. You can do all of that pretty easily with a vanilla redux.

kitten_mittens_ 4y ago

arcanis has a PR to patch up the issue that's sat for a year plus now. https://github.com/microsoft/TypeScript/issues/43632 https://github.com/microsoft/TypeScript/issues/43632 > In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded. In the decade old application we use redux saga in at work, a large portion of our 7MB minified/gzipped main chunk is redux handlers. It'd be nice if there was a relatively simple way to not synchronously load all the reducers up front.

acemarke 4y ago
We have docs on code splitting reducers and other Redux logic here: - https://redux.js.org/usage/code-splitting https://redux.js.org/usage/code-splitting There have been some different community packages for helping with that process, but some of them seem to have become outdated (only worked with React-Redux v5, etc). I did see a new one at https://github.com/fostyfost/redux-eggs https://github.com/fostyfost/redux-eggs that seemed like it had potential, but I haven't had a chance to try any of them myself. I also once saw someone play around with the idea of using React's still-not-technically-final Suspense support to help ensure that a lazy-loaded component that relies on a code-split reducer doesn't actually get rendered until that reducer's state is available. Don't have the link handy atm, but if someone wants it ping me and I can go figure out where that was described. Also, the new RTK "listener" middleware was specifically designed to replace almost all saga usages, and you can dynamically add more listeners at runtime via dispatch an `addListener()` action: - https://redux-toolkit.js.org/api/createListenerMiddleware https://redux-toolkit.js.org/api/createListenerMiddleware - https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/ https://blog.isquaredsoftware.com/2022/05/presentations-evol...

weeksie 4y ago

You don't need _any_ of that. You can use vanilla redux and put your asynchronous code in middleware.

Rumudiez 4y ago
More of this. Middleware is simpler to grok than reducers and provides a clean, universal solution to async. You don’t need sagas, just dispatch events at meaningful points in time, like when a request is initiated and then another action when it completes. Pretty sure Dan Abramov taught this approach years ago in an egghead tutorial, if it takes hearing it from the horse’s mouth to get you to consider not just throwing more libraries at it