#
Customizing queriesRTK Query is agnostic as to how your requests resolve. You can use any library you like to handle requests, or no library at all. By default, RTK Query ships with fetchBaseQuery
, which is a lightweight fetch
wrapper that automatically handles request headers and response parsing in a manner similar to common libraries like axios
. If fetchBaseQuery
alone does not meet your needs, you can customize it's behaviour with a wrapper function, or create your own baseQuery
function from scratch for createApi
to use.
#
Implementing a custom baseQueryRTK Query expects a baseQuery
function to be called with three arguments: args
, api
, and extraOptions
. It is expected to return an object with either a data
or error
property, or a promise that resolves to return such an object.
#
baseQuery function argumentsargs
- The return value of thequery
function for a given endpointapi
- TheBaseQueryApi
object, containingsignal
,dispatch
andgetState
propertiessignal
- AnAbortSignal
object that may be used to abort DOM requests and/or read whether the request is aborted.dispatch
- Thestore.dispatch
method for the corresponding Redux storegetState
- A function that may be called to access the current store state
extraOptions
- The value of the optionalextraOptions
property provided for a given endpoint
#
baseQuery function return value- Expected success result format
- Expected error result format
The type for data
is dictated based on the types specified per endpoint (both queries & mutations), while the type for error
is dictated by the baseQuery
function used.
note
This format is required so that RTK Query can infer the return types for your responses.
#
baseQuery function signatureThe signature of a baseQuery
function is as follows:
A custom baseQuery
need only follow the BaseQueryFn
signature above in order to be used. The examples further on demonstrate multiple implementations of baseQuery
functions to meet different requirements.
#
fetchBaseQuery defaultsFor fetchBaseQuery
specifically, the return type is as follows:
- Expected success result format with fetchBaseQuery
- Expected error result format with fetchBaseQuery
#
Examples#
Axios Base QueryThis example implements a very basic axios-based baseQuery
utility.
- TypeScript
- JavaScript
#
Automatic re-authorization by extending fetchBaseQueryThis example wraps fetchBaseQuery
such that when encountering a 401 Unauthorized
error, an additional request is sent to attempt to refresh an authorization token, and re-try to initial query after re-authorizing.
- TypeScript
- JavaScript
#
Automatic retriesRTK Query exports a utility called retry
that you can wrap the baseQuery
in your API definition with. It defaults to 5 attempts with a basic exponential backoff.
The default behavior would retry at these intervals:
- 600ms * random(0.4, 1.4)
- 1200ms * random(0.4, 1.4)
- 2400ms * random(0.4, 1.4)
- 4800ms * random(0.4, 1.4)
- 9600ms * random(0.4, 1.4)
- TypeScript
- JavaScript
In the event that you didn't want to retry on a specific endpoint, you can just set maxRetries: 0
.
info
It is possible for a hook to return data
and error
at the same time. By default, RTK Query will keep whatever the last 'good' result was in data
until it can be updated or garbage collected.
#
Bailing out of error re-triesThe retry
utility has a fail
method property attached which can be used to bail out of retries immediately. This can be used for situations where it is known that additional re-tries would be guaranteed to all fail and would be redundant.
- TypeScript
- JavaScript
#
Excluding baseQuery with queryFnIndividual endpoints on createApi
accept a queryFn
property which allows a given endpoint to ignore baseQuery
for that endpoint by providing an inline function determining how that query resolves.
This can be useful for scenarios where you want to have particularly different behaviour for a single endpoint, or where the query itself is not relevant. Such situations may include:
- One-off queries that use a different base URL
- One-off queries that use different handling, such as automatic re-tries
- One off queries that use different error handling behaviour
- Leveraging invalidation behaviour with no relevant query
- Using Streaming Updates with no relevant initial query
- TypeScript
- JavaScript
For typescript users, the error type that queryFn
must return is dictated by the provided baseQuery
function. For users who wish to only use queryFn
for each endpoint and not include a baseQuery
at all, RTK Query provides a fakeBaseQuery
function that can be used to easily specify the error type each queryFn
should return.
- TypeScript
- JavaScript
#
Adding Meta information to queriesA baseQuery
can also include a meta
property in it's return value. This can be beneficial in cases where you may wish to include additional information associated with the request such as a request ID or timestamp.
In such a scenario, the return value would look like so:
- Expected success result format with meta
- Expected error result format with meta
- TypeScript
- JavaScript