v2.3.0
This feature release adds a new RTK Query upsertQueryEntries
util to batch-upsert cache entries more efficiently, passes through additional values for use in prepareHeaders
, and exports additional TS types around query options and selectors.
Changelog
upsertQueryEntries
RTK Query already had an upsertQueryData
thunk that would upsert a single cache entry. However, some users wanted to upsert many cache entries (potentially hundreds or thousands), and found that upsertQueryData
had poor performance in those cases. This is because upsertQueryData
runs the full async request handling sequence, including dispatching both pending
and fulfilled
actions, each of which run the main reducer and update store subscribers. That means there's 2N
store / UI updates per item, so upserting hundreds of items becomes extremely perf-intensive.
RTK Query now includes an api.util.upsertQueryEntries
action that is meant to handle the batched upsert use case more efficiently. It's a single synchronous action that accepts an array of many {endpointName, arg, value}
entries to upsert. This results in a single store update, making this vastly better for performance vs many individual upsertQueryData
calls.
We see this as having two main use cases. The first is prefilling the cache with data retrieved from storage on app startup (and it's worth noting that upsertQueryEntries
can accept entries for many different endpoints as part of the same array).
The second is to act as a "pseudo-normalization" tool. RTK Query is not a "normalized" cache. However, there are times when you may want to prefill other cache entries with the contents of another endpoint, such as taking the results of a getPosts
list endpoint response and prefilling the individual getPost(id)
endpoint cache entries, so that components that reference an individual item endpoint already have that data available.
Currently, you can implement the "pseudo-normalization" approach by dispatching upsertQueryEntries
in an endpoint lifecycle, like this:
const api = createApi({
endpoints: (build) => ({
getPosts: build.query<Post[], void>({
query: () => '/posts',
async onQueryStarted(_, { dispatch, queryFulfilled }) {
const res = await queryFulfilled
const posts = res.data
// Pre-fill the individual post entries with the results
// from the list endpoint query
dispatch(
api.util.upsertQueryEntries(
posts.map((post) => ({
endpointName: 'getPost',
arg: { id: post.id },
value: post,
})),
),
)
},
}),
getPost: build.query<Post, Pick<Post, 'id'>>({
query: (post) => `post/${post.id}`,
}),
}),
})
Down the road we may add a new option to query endpoints that would let you provide the mapping function and have it automatically update the corresponding entries.
For additional comparisons between upsertQueryData
and upsertQueryEntries
, see the upsertQueryEntries
API reference.
prepareHeaders
Options
The prepareHeaders
callback for fetchBaseQuery
now receives two additional values in the api
argument:
arg
: the URL string orFetchArgs
object that was passed in tofetchBaseQuery
for this endpointextraOptions
: any extra options that were provided to the base query
Additional TS Types
We've added a TypedQueryStateSelector
type that can be used to pre-type selectors for use with selectFromResult
:
const typedSelectFromResult: TypedQueryStateSelector<
PostsApiResponse,
QueryArgument,
BaseQueryFunction,
SelectedResult
> = (state) => ({ posts: state.data?.posts ?? EMPTY_ARRAY })
function PostsList() {
const { posts } = useGetPostsQuery(undefined, {
selectFromResult: typedSelectFromResult,
})
}
We've also exported several additional TS types around base queries and tag definitions.
What's Changed
- Fix serializeQueryArgs type by @Reedgern in #4658
- Add the
TypedQueryStateSelector
helper type by @aryaemami59 in #4656 - Pass query args to prepareHeaders function by @kyletsang in #4638
- Implement a util function to batch-upsert cache entries by @markerikson in #4561
- fetchBaseQuery: expose extraOptions to prepareHeaders by @phryneas in #4291
Full Changelog: v2.2.8...v2.3.0