Expose queryCacheKey in api baseQuery

[HaakonSvane]

As discussed in this Discord thread

In very broad strokes, a user-facing overview of the different layers of RTK Query looks a little bit like this:

The availability of "query-stable" identifiers is currently a little bit lacking across these layers. As discussed in the Discord thread, it would be helpful to expose queryCacheKey in the arguments of baseQuery in the api definition since this would allow us to create stable identifiers that reference a specific query that we can compare against in other layers as well.

Context

Here is a process diagram showing what I want to achieve on a higher level:

Code flow looks a little bit like this:

In essence, I need to orchestrate the downloading of a set of server endpoints into local device storage so that users can work with my app in offline mode. By moving choice of querying against a remote server vs my local storage futher into the fetching / network layer of my codebase, I can use RTK Query agnostic to how the data is fetched. This has a lot of benefits from an architectural point of view.

In my async thunk download orchestrator, I am dispatching endpoints and storing their resulting data in my local storage. I need a key / id for each of these endpoints that I can store the response data under. In the dispatching layer, the queryCacheKey is available to me, which together with the reducer name should allow me to uniquely set a key for each endpoint in storage. Since this key is not available in the fetching / networking layer however, it is currently impossible for me to query against my local storage since there is no way to retrieve this key based on the contextual arguments that baseQuery is served.

Ideally, I'd want to store the response data by the URL of the endpoint I downloaded the data for since this is expected to be more stable than reducer names and query names (+ arg names). This would require the meta of a query to be exposed in the return value of an awaited query dispatch, which I understand from the Discord thread would be hard to achieve.