Handle pending actions from several asynchronous thunks with one reducer matcher.
Centralized loading state
Redux Toolkit · Function
isPending creates a type-safe matcher for pending createAsyncThunk lifecycle actions. Provide thunks to restrict matches to those action creators, or use the general form to match pending thunk actions.
isPending is a higher-order matcher for createAsyncThunk lifecycle actions. Called with one or more thunk action creators, it returns a type guard that identifies pending actions from those thunks; called without arguments, it can match pending actions generally.
isPending(...actionCreators)| Name | Type | Description |
|---|---|---|
actionCreators | AsyncThunk[] | Optional one or more createAsyncThunk action creators whose pending actions should be matched. |
A type-guard matcher function that returns true for matching pending createAsyncThunk lifecycle actions.
import { isPending } from '@reduxjs/toolkit'
import { requestThunk1, requestThunk2 } from './thunks'
const matchesPending = isPending(requestThunk1, requestThunk2)
const action = requestThunk1.pending('request-1', 'input')
console.log(matchesPending(action)) // trueCreates a matcher for pending lifecycle actions from either thunk.
Centralized loading state
Type-safe action inspection
Global request tracking
isPending returns a matcher function, specifically a type guard, rather than directly returning whether a supplied action is pending. Pass one or more createAsyncThunk action creators, then call the returned matcher with an action.
Follow-up: How can matching be restricted to selected requests? Pass the relevant thunk action creators to isPending, so the resulting matcher only matches pending actions from those thunks.
It checks whether an action represents the pending phase of a createAsyncThunk promise lifecycle. When the matcher succeeds, TypeScript can narrow the action to a pending action type.
Follow-up: What lifecycle phase would you use for completed work? Use the corresponding matching utility documented for that lifecycle phase, such as isFulfilled.
The matcher accepts one or more action creators, and the documentation's example combines requestThunk1 and requestThunk2. The resulting predicate can be supplied wherever a matcher function is expected, such as a reducer builder's matcher handling.
Follow-up: Why use a matcher in reducer logic? It lets one handler respond to a common lifecycle condition across multiple thunk action creators instead of registering separate exact cases.
isFulfilledisRejectedisAsyncThunkActioncreateAsyncThunkaddMatcher