Redux Toolkit · RTK Query · all subjects

cache-management/optimistic-updates

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

updateQueryData usage for optimistic updates

updateQueryData is typically used as the first step in implementing optimistic updates. The generated inversePatches can be used to revert the updates by calling dispatch(patchQueryData(endpointName, arg, inversePatches)). Alternatively, the undo method can be called directly to achieve the same effect.

patchQueryData usage for optimistic updates

patchQueryData is typically used as the second step in implementing optimistic updates. If a request fails, the optimistically-applied changes can be reverted by dispatching patchQueryData with the inversePatches that were generated by updateQueryData earlier. In cases where it is desired to simply revert the previous changes, it may be preferable to call the undo method returned from dispatching updateQueryData instead.

RTK Query supports streaming cache updates

RTK Query enables streaming cache updates, such as updating the initial fetched data as messages are received over a websocket connection.

RTK Query supports optimistic updates

RTK Query has built-in support for optimistic updates that can be implemented by manually updating the cache.

Optimistic update core concepts

The core concepts for an optimistic update are: when you start a query or mutation, onQueryStarted will be executed; you manually update the cached data by dispatching api.util.updateQueryData within onQueryStarted; then, in the case that queryFulfilled rejects, you roll it back via the .undo property of the object you got back from the earlier dispatch, OR you invalidate the cache data via api.util.invalidateTags to trigger a full re-fetch of the data.

Optimistic update with overlapping requests pitfall

Where many mutations are potentially triggered in short succession causing overlapping requests, you may encounter race conditions if attempting to roll back patches using the .undo property on failures. For these scenarios, it is often simplest and safest to invalidate the tags on error instead, and re-fetch truly up-to-date data from the server.

Optimistic update mutation example using async await

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query' import type { Post } from './types' const api = createApi({ baseQuery: fetchBaseQuery({ baseUrl: '/', }), tagTypes: ['Post'], endpoints: (build) => ({ getPost: build.query<Post, number>({ query: (id) => `post/${id}`, providesTags: ['Post'], }), updatePost: build.mutation<void, Pick<Post, 'id'> & Partial<Post>>({ query: ({ id, ...patch }) => ({ url: `post/${id}`, method: 'PATCH', body: patch, }), async onQueryStarted({ id, ...patch }, { dispatch, queryFulfilled }) { const patchResult = dispatch( api.util.updateQueryData('getPost', id, (draft) => { Object.assign(draft, patch) }), ) try { await queryFulfilled } catch { patchResult.undo() } }, }), }), }) This example shows an optimistic update mutation that immediately updates the cache when the mutation is triggered, then rolls back via .undo() if the request fails.

Optimistic update mutation with catch shorthand

onQueryStarted({ id, ...patch }, { dispatch, queryFulfilled }) { const patchResult = dispatch( api.util.updateQueryData('getPost', id, (draft) => { Object.assign(draft, patch) }) ) queryFulfilled.catch(patchResult.undo) } This is a shorter version of the optimistic update pattern using .catch instead of try/catch.

Give your agent this brain