Gaps between queryClient and useQuery API

[carpben]

The issue

queryClient.prefetch doesn't accept and doesn't trigger onSuccess while useQuery(fetchingObject) does.
This is an issue because:

1. I think it is of value that the various fetching triggering consumers use a similar API. This can allow separating the logic for a specific fetch from the specific trigger. So if we are fetching for a post list

const postListQueryParams = {
  queryKey: "postList", 
  queryFn: ... 
  onSuccess: ...
}

we can then use the same object for the different triggers, such as useQuery and queryClient.prefetch.

function Comp1(props){
  const queryResult = useQuery(postListQueryParams)
  ....
}

function Comp2(props){
  const queryResult = useQuery(postListQueryParams)
  ....
}

// Before Comp1 and Comp2 are in the UI 
queryClient.prefetch(postListQueryParams)

2. onSuccess could be very helpful when prefetching.

[TkDodo]

onSuccess is a parameter that only exists no an observer level, and since prefetchQuery (or even fetchQuery) don't create a subscription, there is no onSuccess callback. It's also briefly mentioned in the docs here

[TkDodo]

That’s indeed interesting. I’d need to take a closer look on why this is happening and what the expected behavior is.

[TkDodo]

is this just a type level issue? From what I can see, the options are gathered as usual from what you pass in and what the defaults are, so I think both ways should work. But yeah, I can see that we don't have those on the typescript types 🤔

[carpben]

My experience was that the behaviour is different. When passing onSuccess directly to prefetch it didn't run, and when passing to to setQueryDefaults it did run. If this isn't your experience I'll be happy to try to create a CodeSandBox.

[TkDodo]

A sandbox would be great

[carpben]

I think I made a mistake. Perhaps because on one page prefetch ran alone, and on the other it ran parallel to useQuery.