Intended usage of queryFn's baseQuery parameter #3886
-
In Implementing a queryFn, the
However, the
whereas a "global" baseQuery (ex. as produced from
ie. the one passed in to 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 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
As you noted, you don't need to pass the 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. |
Beta Was this translation helpful? Give feedback.
As you noted, you don't need to pass the
api
andopts
options to thebaseQuery
function passed as the fourth parameter forqueryFn
, 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.