Expose QueryClient object in callbacks

[Jeday]

Problem

Lifecycle hooks are primarily used to orchestrate invalidation,optimistic updates and etc and heavily rely on current QueryClient object. Yet we have to manually provide it every time which forces callback functions to be declared in react scope.

const qc = useQueryClient()
useQuery({
  ...params,
 onSuccess: ()=>{
  qc.invalidateQueries(...)
}
}) 

Proposed solution

Provide QueryClient as a last argument to all major callback functions

onSuccess: (data, variables, _,qc)=>{
  qc.invalidateQueries(...)
}

Extra

Could we provide an easier way to bundle callbacks? Right now if you want to encapsulate and reuse your queries, separating UX/Data logic in callbacks as well you have to resort to self-written callback merging. Example: internal onSuccess invalidates data, external pushes the router page.

[louis-young]

Hi 👋

At face value, this seems like a nice thing to do 🙂

To address the extra question - this is partly why you can specify callbacks at query client, hook, and at mutation function level (in the case of mutations). It's a little easier with mutations as you can perform data/cache-related side effects in the hook callbacks, and UI-related side effects in the mutation function callbacks. Are you proposing we expose some form of callAll utility function, or support an array of callbacks, or something else entirely?

[Jeday]

Glad to see positive feedback on this. I think it would be a right step towards platform agnosticism of RQ.

On extra matter - If this gains interest I can build up a separate thread with proper examples. In short, I used custom hooks e.g. useCreatePost where inside I'd have all logic needed for invalidation and etc. Yet trough return value and arguments I would expose as much of original query object as I can. Because I want to be able to add/overwrite behavior depending on situation. This forced me to merge options and most importantly callbacks. So array of callback sounds like what I had in mind.

[TkDodo]

it's not easily possible to provide the queryClient to callbacks, because the client depends on usage, but a query / mutation is a separate entity. Theoretically, you can have the same query run under different providers with different clients. Yes, it would be two observers and the callbacks are on observer-level, so we could make that work, but I don't think we could pass the client to the cache level callbacks then, creating an incoherent api.

let's try to solve the problem from a different angle. If you want automatic invalidation without accessing the client, this can work:

https://twitter.com/TkDodo/status/1630321212013387776