Intended usage of queryFn's baseQuery parameter

[MustafaHaddara]

In Implementing a queryFn, the queryFn is described as

A queryFn can be thought of as an inline baseQuery. It will be called with the same arguments as baseQuery, as well as the provided baseQuery function itself (arg, api, extraOptions, and baseQuery).

However, the baseQuery that gets passed in to queryFn is not the same as the "global" baseQuery. My TS compiler tells me it has the following type:

(arg: string | FetchArgs) => MaybePromise<QueryReturnValue<unknown, FetchBaseQueryError, FetchBaseQueryMeta>>

whereas a "global" baseQuery (ex. as produced from fetchBaseQuery) will have the type

(args: string | FetchArgs, api: BaseQueryApi, extraOptions: {}) => MaybePromise<QueryReturnValue<unknown, FetchBaseQueryError, FetchBaseQueryMeta>>

ie. the one passed in to queryFn only accepts that first string | FetchArgs parameter.

The "automatic re-auth" example seems to suggest a pattern like this (truncated for convenience):

const baseQuery = fetchBaseQuery();

const api = createApi({
  baseQuery,
  endpoints: (builder) => ({
    getMyThing: builder.query({
      queryFn: async (args, api, opts, /* unused! */) => {
        let result = await baseQuery(args, api, opts);
        // etc...
      },
    }),
  }),
});

whereas I would expect to be able to do this:

const api = createApi({
  baseQuery: fetchBaseQuery(),
  endpoints: (builder) => ({
    getMyThing: builder.query({
      queryFn: async (args, api, opts, /* now used */ baseQuery) => {
        let result = await baseQuery(args, api, opts); // now this is a type error, because this `baseQuery` only accepts 1 arg, not 3. 
        // etc...
      },
    }),
  }),
});

What is the intended usage of the baseQuery param? Should I be passing api and opts to it, or not?

[EskiMojo14]

As you noted, you don't need to pass the api and opts options to the baseQuery function passed as the fourth parameter for queryFn, as RTKQ will already provide them.

Both codeblocks are valid - it's essentially preference whether you'd rather save baseQuery to a reusable variable or get it back out from the parameter. In general I'm inclined to agree that the parameter approach is simpler.

[MustafaHaddara]

you don't need to pass the api and opts options to the baseQuery function passed as the fourth parameter for queryFn, as RTKQ will already provide them.

Oh nice, that's convenient. Is that documented anywhere?

[EskiMojo14]

It's in the queryFn API documentation

[MustafaHaddara]

It...isn't? I can see the API documentation describing the type of baseQuery as simply (arg: Parameters<BaseQuery>[0]) => ReturnType<BaseQuery>, but the text of the documentation says that it is "The baseQuery function provided to the api itself"?

---

On another note, if I may provide a bit of feedback, I find this interface a little awkward. Now I'm writing this:

queryFn: async (args, api, opts, baseQuery) => {
  let result = await baseQuery(args);
  // etc...
},

but since baseQuery will automatically pass through api and opts, I think that the majority of use cases where I want the baseQuery param, I will never need the api or opts params, and then I get lint warnings for unused params.

I think I'd prefer being able to do

queryFn: async (args, { baseQuery }) => {
  let result = await baseQuery(args);
  // etc...
},

[EskiMojo14]

It...isn't? I can see the API documentation describing the type of baseQuery as simply (arg: Parameters[0]) => ReturnType, but the text of the documentation says that it is "The baseQuery function provided to the api itself"?

Any wording changes to make it clearer would be welcome in a PR 🙂

On another note, if I may provide a bit of feedback, I find this interface a little awkward. Now I'm writing this

That would be a breaking change, but we're actually collecting feedback for RTK Query in a possible 3.0 - feel free to suggest the change over there!