createAsyncThunk and centralized/generic error and pending state management

[jondot]

Hi,
Looking at existing examples and trying to borrow from real-world experience, I'm wondering if there is a best practice people are using to model:

1. A request is pending or failed in the app somewhere (traditionally done with a dedicated request store)
2. A specific async action is now pending or failed

And having the state: pending, error layered out automatically for these.

In the past I've used to use some generic middleware (in rematch) that tracks all requests and builds the following tree:

pending: true|false
actions: {
   <reducer> {
            <action-name>: pending
   }
}

And then I could query it with a selector for any use case I wanted. The same tree exists for error states.

Looking at redux-toolkit and the createAsyncThunk, I can't help but think -- there must be something like that already, rather than hand-coding addCase for all the actions, etc.

I've:

1. searched the discussion board for such a thing, found nothing close
2. looked at example in docs but it contained a starting point that assumes a reducer has only 1 API call, and it's obvious that this will multiply as we have more async calls
3. acknowledged the fact that RTQ is the way forward for all things async, but still am wondering about non-RTQ use cases

Any ideas?

[phryneas]

Well, the point is that we are shipping RTK Query which uses createAsyncThunk do do exactly this. If you don't want to use RTKQ, you essentially have to build that part yourself.

[jondot]

Can RTKQ be used for one-offs API workflows? (specifically, just an involved --for reasons-- authentication flow)
E.g. for how this looks like in the wild (not my project, I just like to github-search 'createAsyncThunk' and follow the breadcrumbs):
https://github.com/minnu-v/management/blob/d4bcd9a72959180f1508be46b6fd690adc36f5e8/src/store/reducer/requestReducer.js

[jondot]

Or another example from the docs:

Where the concern of making the request (RTKQ) + setting the result, becomes the component's concern -- I'm wondering if that's good design in general?
Also -- if that's where the workflow is managed -- i'm not sure i even need a 'loading' or 'error' state, because I can do it by looking at the direct dispatch result, and createAsyncThunk works well.
It's only an issue where pending and error are in the state

Sorry for throwing another question at you -- but i'm wondering whats the point in keeping the pending and error statuses in the state at all, when I can do all the workflow in the component and wait on a promise and look at its results

[phryneas]

Here you have two different approaches of handling that setCredential without involving the component, straight from the docs: https://redux-toolkit.js.org/rtk-query/usage/examples#authentication

[jondot]

Sorry I just edited -- could you also give your take on the last part of the question? (the point of keeping this at the state at all)

[phryneas]

Synchronization: often you want the same data in multiple components and if you only have it locally everywhere, for one you will do the same request over and over, but also you might have data in different states, so component A shows outdated data while component B shows up-to-date data.