RTK Query usage feedback for 2.x planning

[markerikson]

We're starting on the RTK Query work in the 2.x and 3.0 roadmap. Several of the upcoming 2.x releases change how RTKQ tracks requests and writes to the cache. Before we lock in those behaviors, we'd like to know how you actually use them today.

Real code examples help the most, even short snippets. "We do X because Y" is more useful to us than "X would be nice".

Reading the cache directly

• Do you read state.api.queries or state.api.mutations directly, instead of through the endpoint selectors? What for?
• Do you iterate over the cache entries, or look them up by cache key?

In 3.0 the query cache moves to queries[endpointName][cacheKey] (#5503), so we want to know what that breaks and what selectors or utilities would replace your current code.

initiate() promises and request timing

• Do you await dispatch(api.endpoints.x.initiate(arg)) and use the value it resolves to? What happens if that request was deduped against one already in flight?
• Do you use forceRefetch, subscribe: false, or manual unsubscribe() calls? What for?

In 2.15 the initiate() promise always resolves with the result of its own request (#5506). That's a behavior change, so we want to know who depends on the current behavior.

Invalidation while a request is pending

• If a mutation invalidates a tag while a query with that tag is still fetching, what do you expect to happen? Should the in-flight result be thrown away, should the query refetch after it finishes, or something else?
• If you write to the cache with updateQueryData or upsertQueryData while a fetch for that entry is in flight, which result do you expect to win?
• Have you written workarounds for either of these cases?

These answers feed directly into the invalidation work (#5510, #5511) and into which of these behaviors becomes the default.

SSR, hydration and persistence

• Do you use extractRehydrationInfo? With which setup (Next.js pages or app router, redux-persist, something custom)?
• Do you persist the RTKQ slice to storage? Do you persist all of it, or only some endpoints?
• Do you need to hydrate entries that are still pending on the server, such as streamed SSR results?

We plan to add dehydrate / hydrate utilities in 2.17 (#5515), and they will be the supported way to carry cache data across the 3.0 upgrade.

Answers on any subset of these are welcome. Feedback on the 3.0 API changes goes in [the 3.0 breaking changes discussion].

[popuguytheparrot]

needs features like subs on cache key, like in tanstack-query.
needs suspense query like in tanstack-query.

needs fix generated hooks export, now if use... hook from api exported as {use...} in IDE jump to source not follow to api creator, stops only on export. Now i using hooks like api.endpoints.post...useQuery(). Click to post... jump in ide to field in api creator.

also with initiate, on tanstack-router i dispatch some data like .initiate() with unsub or manual call. We use codegen from openapi like contract and fetch layer.

needs improve rtk query codegen like kubb.dev for tanstack-query.
needs zod schemas, msw support, and other features from kubb.

[EskiMojo14]

the jump to source issue is a typescript limitation, it only supports that for homomorphic mapped types - we need key remapping (to turn getFoo into useGetFooQuery) so the link is broken

[markerikson]

@popuguytheparrot can you clarify what you mean by "subs on cache key"?

Suspense support is planned, probably around 2.17ish:

• Tracking: RTKQ Suspense and React hooks #5490

[popuguytheparrot]

RTK Query lacks a public API for subscribing to cache changes by query key, similar to TanStack Query's QueryCache.subscribe() and QueryObserver.

It also lacks an equivalent to MutationCache.subscribe() for observing mutation events.

While these behaviors can be approximated using store.subscribe(), selectors, and listener middleware, they require additional boilerplate and don't provide the same event-driven API.

[markerikson]

@popuguytheparrot gotcha. what's your use case for subscribing to those? When do you initiate them, what do you use them for? Can you show some examples?

[wirdehall]

Reading the cache directly

Do you read state.api.queries or state.api.mutations directly, instead of through the endpoint selectors? What for?

In a very specific edge-case do we use state.api.queries. In the 3 endpoints for updateing our cart items we have the built-in side-effect that it will automatically call our analytics api and update the cart items there as well. So on onQueryStarted we get the item from the cache and once the queryFulfilled promise is fullfilled we dispatch the analytics action with the change. Here's an example:

async onQueryStarted(args, api) {
  const { dispatch, queryFulfilled } = api;
  const state = api.getState();
  const orderItem = (state.cartApi.queries['getCart(undefined)']?.data as CartTypes.Order).items.filter((orderItem) => orderItem.id === args.orderItemId)[0];
  await queryFulfilled.then(async ({ data: updatedCart })=>{
    await dispatch(cartApi.util.upsertQueryData('getCart', undefined, updatedCart));
    if(updatedCart !== null) { // We don't need to await this, it can happen eventually, it's not critical for moving forward.
      if(args.amount > orderItem.amount) {
        dispatch(AnalyticsActions.addToCart({ supplierTireId: orderItem.supplierTireId, amount: args.amount - orderItem.amount }));
      } else {
        dispatch(AnalyticsActions.removeFromCart({ orderItem, amount: orderItem.amount - args.amount }));
      }
    }

initiate() promises and request timing

Do you await dispatch(api.endpoints.x.initiate(arg)) and use the value it resolves to? What happens if that request was deduped against one already in flight?

Again to solve a very specific problem we where facing. 3 cases in one app and 1 case in another. All of them steming from the same problem, we need to fetch data outside of react scope.
In the same app as the example above it's related to the same thing, the AnalyticsActions are setup as effects. In there we need to fetch data about the products so we fetch it using initiate, await the promise, then promptly unsubscribe.
In the other app we have 3 use-cases:

1. We need to fetch some data before we initiate react to pass to our router.
2. When lazyLoading code-chunks we check if there has been a new release of the frontend, if so we will reload the application before fetchin a chunk that no longer exists. Again we are outside of the react component-structure.
3. When logging in but before react get's another rerender we need to re-fetch the data we fetched in point 1 and update it in our store so the application doesn't try to rerender without the updated context.

Do you use forceRefetch, subscribe: false, or manual unsubscribe() calls? What for?

All of these are used in some combination or other in the examples above.
For forceRefetch we use it quite liberally. We have wrapped the endpoint definitions in our admin application.
I think this needs a little bit of context on why we did this, sorry if it get's a bit long.
We have a multi-webshop system, in the admin applicaiton you can administrate all the different webshops and also administrate things on a top level, things that affect all webshops equally. So to forgo the need to write so much boilerplate in each react component (fetching which webshop we are currently in, and passing that into literally every api call in the entire application) we wrote a small wrapper that checks if the request is webshop dependent. If so it will force a refetch if we switched webshop since we last made this call with these parameters.
This little wrapper was something I built over 2 years ago, haven't needed to touch it since, it just works. It would be a huge rewrite of our entire application if we suddently didn't have access to this since we would need to start passing webshopId in as a parameter in 90%+ of all our requests.

Invalidation while a request is pending

If a mutation invalidates a tag while a query with that tag is still fetching, what do you expect to happen? Should the in-flight result be thrown away, should the query refetch after it finishes, or something else?

I don't think we have ever encountered a problem with this but as a though experiment I guess refetch after it finishes would make sense?

If you write to the cache with updateQueryData or upsertQueryData while a fetch for that entry is in flight, which result do you expect to win?

Again I don't think we ever encountered a problem with this. And honestly I don't know. I feel like this would be a case-by-case thing. I don't think you can say categorically that one way or the other is the best solution. I would expect that once you run into this problem you have a very specific edge-case and would need to be able use the solution that matches your edge-case. So configurable would probably be the way to go here.

SSR, hydration and persistence

Do you use extractRehydrationInfo? With which setup (Next.js pages or app router, redux-persist, something custom)?

We don't use extractRehydrationInfo, instead we initialize the entire store with preloadedState as hydration. Our setup is custom built.

Do you persist the RTKQ slice to storage? Do you persist all of it, or only some endpoints?

We do persist the logged in customer and carts in local storage so we can sync them across tabs.
That's only data from two specific endpoints though so we don't store the entire slice.

Do you need to hydrate entries that are still pending on the server, such as streamed SSR results?

No. Not found a use-case for that yet.

---

Thanks for all your hard work!