|
| 1 | +# queryThunk |
| 2 | + |
| 3 | +## Overview |
| 4 | +A core action instantiated during (buildThunks). `queryThunk` leverages `createAsyncThunk` to initiate the query process and is used extensively throughout the codebase both as a match case and to initiate queries. The payload for the query is built using [executeEndpoint] |
| 5 | + |
| 6 | +## Functions |
| 7 | +Before executing the payload creator function in [executeEndpoint], `queryThunk` executes two functions: |
| 8 | + |
| 9 | +### `getPendingMeta()` |
| 10 | +1. `getPendingMeta()` - adds additional metadata to the action to be used in reducers or middleware. |
| 11 | + 1. `startedTimeStamp` |
| 12 | + 2. `SHOULD_AUTOBATCH` |
| 13 | + |
| 14 | +### `condition()` |
| 15 | + |
| 16 | +Performs conditional checks based on the provided args to decide whether the query should continue or not. (also attaches the field `dispatchConditionRejected: true` as confirmation that the condition was checked) |
| 17 | +```ts no-transpile |
| 18 | +if (isUpsertQuery(queryThunkArgs)) { return true } |
| 19 | +if (requestState?.status === "pending") { return false } |
| 20 | +if (isForcedQuery(queryThunkArgs, state)) { return true } |
| 21 | +if (isQueryDefinition(endpointDefinition) && endpointDefinition?.forceRefetch?.({ return true } |
| 22 | +if (fulfilledVal) { return false } |
| 23 | +else return true |
| 24 | +``` |
| 25 | +
|
| 26 | +## Middleware Uses |
| 27 | +
|
| 28 | +### buildSlice |
| 29 | +The query endpoint is built almost entirely off of the `extraReducers` matching a `queryThunk` pending/fulfilled/rejected actions and updates the `querySubstate` plus meta data accordingly. The query slice utilises the condition and attached metadata created by a `queryThunk`. |
| 30 | +
|
| 31 | +`buildSlice` additionally matches resolved (rejected OR fulfilled) `queryThunks` to update providedTags. |
| 32 | +
|
| 33 | +### invalidationByTags |
| 34 | +matches against all rejected/fulfilled cases for `queryThunk` |
| 35 | +
|
| 36 | +### Polling |
| 37 | +matches against multiple queryThunk cases |
| 38 | +```js no-transpile |
| 39 | +if (queryThunk.pending.match(action) || queryThunk.rejected.match(action) && action.meta.condition) { |
| 40 | + updatePollingInterval(action.meta.arg, mwApi); |
| 41 | +} |
| 42 | +if (queryThunk.fulfilled.match(action) || queryThunk.rejected.match(action) && !action.meta.condition) { |
| 43 | + startNextPoll(action.meta.arg, mwApi); |
| 44 | +} |
| 45 | +``` |
| 46 | +
|
| 47 | +### cacheLifecycle |
| 48 | +uses `queryThunk` matching to differentiate between mutation cache and query cache handling |
| 49 | +
|
| 50 | +### queryLifecycle |
| 51 | +leverages the createAsyncThunk pending/fulfilled/rejected to extend the lifecycle with query specific traits, also uses it to handle onQueryStarted |
| 52 | +
|
| 53 | +### batchedActions |
| 54 | +
|
| 55 | +### buildMiddleware |
| 56 | +
|
| 57 | +`refetchQuery` refires queryThunk with arguments for the `queryThunk` to determine if the query should be sent or not |
0 commit comments