4 ms·

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior. I wrote about why I chose thunks as the default in our Redux Toolkit package: https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux-toolkit-uses-thunks-for-async-logic/ https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh... and our Style Guide docs page specifically recommends using thunks as a default: https://redux.js.org/style-guide/style-guide#use-thunks-for-async-logic https://redux.js.org/style-guide/style-guide#use-thunks-for-...

cageface 7y ago
I had to rescue a codebase that was all-in on sagas by developers that didn't seem to really understand what they were for. It was one of the most difficult and frustrating projects I've ever worked on. Debugging was a total nightmare because bugs were so decoupled from their causes. I'm sure there are cases where, in the right hands, sagas can help solve complex problems but, like redux, they are overused by people that are just following the herd and can create a ton of accidental complexity.
nickbauman 7y ago
One of the things I love about ClojureScript's Reagent library is that I will never need something like Redux because Clojure has was Redux does "for free." Reactive state management is baked in at the language level.
kilburn 7y ago
I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say: > If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable. Aren't these kind of things necessary for really robust applications? For instance, let's say my app fetches some "posts" list and shows it as a table. I have so many "posts" that I'll do server-side pagination. With a naive thunk, if the user clicks on "page 2" and then quickly on "page 3" it is perfectly possible that she ends in "page 2" (because that request happened to complete after the one for "page 3"). How are we supposed to deal with these things with thunks?
- acemarke 7y ago
  Cancellation is definitely something that is trickier with thunks. We recently added a new `createAsyncThunk` API [0] to our Redux Toolkit package, which has built-in support for signaling some kind of cancellation using an AbortController [1], but how that gets used in relation to your actual async call and how your reducer processes the responses is up to you. Cancellation, debouncing, and other "thread-like" behaviors are where sagas are truly useful. But, in most cases folks are just trying to do simple AJAX requests for data fetching, and trying to learn how to configure and use sagas just for that is way too much overhead. [0] https://redux-toolkit.js.org/api/createAsyncThunk https://redux-toolkit.js.org/api/createAsyncThunk [1] https://redux-toolkit.js.org/api/createAsyncThunk#cancellation https://redux-toolkit.js.org/api/createAsyncThunk#cancellati...

cageface 7y ago

I had to rescue a codebase that was all-in on sagas by developers that didn't seem to really understand what they were for. It was one of the most difficult and frustrating projects I've ever worked on. Debugging was a total nightmare because bugs were so decoupled from their causes. I'm sure there are cases where, in the right hands, sagas can help solve complex problems but, like redux, they are overused by people that are just following the herd and can create a ton of accidental complexity.

nickbauman 7y ago

One of the things I love about ClojureScript's Reagent library is that I will never need something like Redux because Clojure has was Redux does "for free." Reactive state management is baked in at the language level.

kilburn 7y ago

I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say: > If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable. Aren't these kind of things necessary for really robust applications? For instance, let's say my app fetches some "posts" list and shows it as a table. I have so many "posts" that I'll do server-side pagination. With a naive thunk, if the user clicks on "page 2" and then quickly on "page 3" it is perfectly possible that she ends in "page 2" (because that request happened to complete after the one for "page 3"). How are we supposed to deal with these things with thunks?

acemarke 7y ago
Cancellation is definitely something that is trickier with thunks. We recently added a new `createAsyncThunk` API [0] to our Redux Toolkit package, which has built-in support for signaling some kind of cancellation using an AbortController [1], but how that gets used in relation to your actual async call and how your reducer processes the responses is up to you. Cancellation, debouncing, and other "thread-like" behaviors are where sagas are truly useful. But, in most cases folks are just trying to do simple AJAX requests for data fetching, and trying to learn how to configure and use sagas just for that is way too much overhead. [0] https://redux-toolkit.js.org/api/createAsyncThunk https://redux-toolkit.js.org/api/createAsyncThunk [1] https://redux-toolkit.js.org/api/createAsyncThunk#cancellation https://redux-toolkit.js.org/api/createAsyncThunk#cancellati...