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].