give useQuery 's onSuccess access to queryKey

[Shaddix]

This request is similar to #268, except that I'm talking about useQuery, not useMutation.

In general, it'd be nice to know http request parameters in onSuccess handler of useQuery. According to the docs it's good pattern to put http parameters in queryKey, to naturally create different keys for different http requests.

Why do we need to know request parameters in onSuccess?
I think that scenario could be similar to the one described in #268. If two queries logically share some data, it makes sense to update cached values of one of them when another is received.

Here's a 'real' example:
We have a master/detail page with a list of users with their names (on Master), and details of a single user (on Details).
Master and Details are shown within one screen.
When we request Details for the User there could be that the Name of the User is different from the one displayed in the List (because it was just changed by someone else).
We'd like to update the cache of the List query, if we received a different Name in Details query.

If we say that List results look like this:
/users: [{id: 1, Name: 'John'}, {id: 2, Name: 'Helen} ]
and Details results look like this:
/user/1 {Name: 'John', LastName: 'Doe', ... }
If there's no id field in details result, it becomes impossible to update the cache of the List in onSuccess handler of Details query.

[TkDodo]

the issue you are linking was about variables, which are not available in a closure, because they are provided by the consumer of the hook when .mutate is called. useMutation also has a mutationKey, which is optional, but it's also not available in the callbacks, because you can access it via closures. The same goes for queryKey:

const usePosts = (id) => {
    const key = ['posts', id]
    return useQuery(key, () => fetchPost(id), { onSucces: () => doSomethingWithKey(key) })
}

We'd like to update the cache of the List query, if we received a different Name in Details query.

you also have the id in the closure, so you can iterate over the items in the queryCache of the list query and update depending on the id.

[Shaddix]

You are right, I see the difference of my request from #268.

One thing that I missed to add, is that we'd like to use queryClient.setQueryDefaults(['user'], { onSuccess: ()=> {/*some handling here*/} }, where our actual query keys are ['user', userId] (e.g. ['user', 1], ['user', 2], etc).

Now onSuccess is called when we set it up like that, but we don't have access to a full queryKey.