This feature preview release adds new options and improves behavior for RTK Query.
As of this alpha, RTK 1.9 is feature-complete and we do not expect additional meaningful changes. The remaining work is filling out docs and preparing the "object reducer" codemods for release alongside 1.9.
Still no specific ETA for release, but we hope for Soon (TM) :)
Changelog
upsertQueryData API
RTKQ already has an updateQueryData util to synchronously modify the contents of an existing cache entry, but there was no way to create a new cache entry and its metadata programmatically.
This release adds a new api.util.upsertQueryData API that allows creating a cache entry + its data programmatically. As with the other util methods, this is a thunk that should be dispatched, and you should pass in the exact cache key arg and complete data value you want to insert:
dispatch(
api.util.upsertQueryData('post', '3', {
id: '3',
title: 'All about cheese.',
contents: 'I love cheese!',
})
)RTKQ Middleware Performance Optimizations
RTKQ automatically generates a Redux middleware for each "API slice" / createApi call. That middleware itself has been made up of 7 individual middleware internally composed into the final middleware, with each individual middleware responsible for a different task like managing polling or cache lifetimes.
While this worked well for encapsulating responsibilities, it also meant that every dispatched Redux action had to go through 7 additional middleware. This added multiple function calls to each dispatch's stack trace, and even if there isn't a noticeable perf hit, it wasn't efficient. We've also had some reports that users with multiple API slices were occasionally seeing "Maximum call stack size exceeded" errors.
We've rewritten the internals of the middleware to be more efficient. Actions now only receive extra processing if they're actually related to the API slice itself, and that processing is done via a loop over handling logic at the end of the middleware unwind phase, rather than nesting function calls through multiple sub-middleware. That should keep the call stack shorter in the cases where API actions really are being processed.
Other RTKQ Updates
The refetch() methods now return a promise that can be awaited.
Query endpoints can now accept a retryCondition callback as an alternative to maxRetries. If you provide retryCondition, it will be called to determine if RTKQ should retry a failed request again.
What's Changed
- return promise from query result & hook
refetchby @phryneas in #2212 - retry condition by http error response by @kahirokunn in #2239
- implemented upsertQueryData functionality per #1720 #2007 by @barnabasJ in #2266
- Consolidate RTKQ middleware to simplify stack size by @markerikson in #2641
- Add TS 4.8 to the test matrix by @markerikson in #2642
- Try fixing createAsyncThunk issues with TS 4.8 by @markerikson in #2643
- Fix assorted issues with the RTKQ middleware refactor by @markerikson in #2644
Full Changelog: v1.9.0-alpha.0...v1.9.0-alpha.1