3 ms·
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 compl
by kilburn 6y 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 6y agoCancellation 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...