Return the QueryKey from useQuery

[shughes-uk]

Generally we defining one hook that creates the query, and then reusing it all over our codebase

export const useSomeThing = (someArg,Arg2):QueryResult => {
    return useQuery(["getSomeThing", someArg,Arg2] , ()=> "barf")
}

We have a couple of components that accept a query key so they can monitor specific queries (a refetching indicator for example)

It would be nice if useQuery returned the querykey, this would allow us to easily pass it around to the relevant components. Right now we tend to use a constant for the string part of the query key and pass that in, which is "ok".

[TkDodo]

I'd recommend the queryOptions function to abstract those away, and export it as a re-usable object:

export const someThingQuery = (someArg,Arg2) queryOptions({
  queryKey: ["getSomeThing", someArg,Arg2],
  queryFn: () => "barf"
})

you can then pass this to useQuery as well as to other functions like invalidateQueries or even useQueries.

Returning the values from useQuery doesn't make much sense because you can only then pass it down to components below that query, which doesn't cover cases where you need it in a sibling component. Calling the hook just to get the queryKey is also suboptimal, because it creates another subscriber. What you likely want is to abstract away the options.

[csepulv]

FWIW, I have the same request and found this issue as I was looking for the same thing. To elaborate, when using useQueries, the results has an array where the positions (indices) do match what was given to useQueries, but the book keeping of matching the query with the result has to be done in my code.

While this is manageable, it would be more convenient if the queryKey was returned in in the result. The queryKey already contains the domain identifiers, encoded in my key, which makes result-to-query identification easy, if I had the queryKey in the result.

[jasongerbes]

@TkDodo would you be willing to reconsider this request?

I have a reusable query hook that determines the queryKey based on several optional props used by the load function. A child component needs to know the queryKey to invalidate the query after a mutation, but doesn't have the context required to recreate the queryKey.

My current workaround is to use a custom UseQueryResultWithKey type to include the queryKey so that it can be passed to the child component:

import { type QueryKey, useQuery, type UseQueryResult } from '@tanstack/react-query';

export type UseQueryResultWithKey<TData = unknown, TError = unknown> = UseQueryResult<TData, TError> & {
  queryKey: QueryKey;
};

export function useExampleQuery(identifiers: { id1?: string; id2?: string }): UseQueryResultWithKey<unknown, unknown> {
  const queryKey = ['example', identifiers];

  const query = useQuery({
    queryKey: queryKey,
    queryFn: () => loadFunction(identifiers)
  });

  return { ...query, queryKey };
}

[TkDodo]

I am thinking about this functionality, yes, but since the QueryKey is generically typed, we would need to add more type parameters to the UseQueryResult and mostly, it’s not worth it.

but doesn't have the context required to recreate the queryKey.

instead of passing the queryKey to the child component, you can also pass the identifiers so that it can re-build the key. Or, you would invalidate more broadly: queryClient.invalidateQueries(['example'])

or, you create the key and pass it down?

const queryKey = getKey(many, optional, props)

const query = useQuery({ queryKey, queryFn })

<ChildComponent queryKey={queryKey} />

why does it matter here if the queryKey is returned from useQuery or you extract the one you pass to useQuery to a constant?

[Devon-Dickson]

I'm working through the v4 to v5 migration and have reached the deprecation of remove from useQuery. The recommended replacement is to call queryClient.removeQueries({ queryKey }).

@TkDodo Your last message suggests rebuilding the queryKey which is doable, but would imply exporting the queryKeyFactory from queries.ts which you didn't recommend in this blog post.
https://tkdodo.eu/blog/effective-react-query-keys#colocate

Exceptions are sometimes necessary, but I wanted to call this out in case there was something I was misunderstanding!

edit: While revisiting the blog I noticed your newer post on Query Options, which looks like an even better approach!
https://tkdodo.eu/blog/the-query-options-api

[zumm]

@TkDodo

What about returning queryKey hash? It would be helpful for my case. Im trying to write wrapper around queries to notify user about errors by toast. Something like that:

const query = withNotification(useQuery(options))

Since there may be multiple attempts to fetch data i don't want to spam user with same notification. So i use some notification id to filter notifications and queryKey hash is best choise for that id here. At this moment i have to pass queryKey to my withNotification explicitly, resolve it (since it may be wrapped in framework things) and hash. This is unnecessery boilerplate and overhead. Would be very nice to be able to get it from useQuery (useInfiniteQuery, useMutation, etc).

[okgoodlife]

Not an answer to the original question, this is for people who find this thread for the same or a similar reason as me:

TLDR:
Depending on your circumstances it is possible to use the select field of the queryOptions to group the key with the result data to preserve the relationship.

I was working on a specific case in our API where the query key contains information that is not easy to get from the returned data.

I was trying to achieve batching like this example:

hook Calls for [a, b, c] and for [b, c, d] get turned into two useQueries-calls with three queries each (to make use of useQueries awesome batching), and then batched to one API call of [a, b, c, d]. This would result in an API return value of {a: valA, b: valB, c: valC, d: valD}, with all the values getting cached separately.
To reiterate, valA does not contain an easy way to get the key a.

I was trying to batcher-resolve this result into {a: valA, b: valB, c: valC} and {b: valB, c: valC, d: valD} (to preserve the interface for the code using the hook), but since QueryResult does not contain the key, all I had was three arrays of QueryResults [resultA, resultB, resultC] and [resultB, resultC, resultD].
Since getting from resultA to a is hard, it is also hard to go from [resultA, resultB, resultC] to {a: valA, b: valB, c: valC}.

The ensuing research brought me here. After finding out that the key is not part of the result on purpose, I spent some time trying to come up with an alternate solution. Luckily, I thought of adding a selector to my mapped queries in useQueries:
queries: keys.map(key => ({ // [...] queryFn: () => batcher.fetch(key), select: data => ({ key, data }) }))
The resulting arrays of queryResults contain both key and data in their data field.

This took me some time to work out, hope it helps someone else in a similar situation in the future!

[TkDodo]

you can also just amend it to whatever you return from the queryFn

[okgoodlife]

So change the API endpoint
from (keys: string[]) => ({[key in keys]: SingleResult})
to (keys: string[]) => ({[key in keys]: SingleResult & {key: string})?
([key in keys] only used to illustrate what keys the object will have, not really as a type)

in my particular situation, the keys of SingleResult are also dynamic (Legacy code is fun), and I wanted to retain the ability to iterate over them in the code that is using my hook, so that wasn't an option unfortunately.
Or rather, I am two layers of abstraction deep right now and don't want to risk anyone looping over the keys somewhere.

I do agree that this would be easier in many situations, thanks for your reply!
My solution does not require changes in the code using the hooks or in the endpoint, so maybe it's helpful for someone in a similarly restricted situation.

[TkDodo]

I meant:

- queryFn: () => batcher.fetch(key), select: data => ({ key, data }) })
+ queryFn: async () => {
+  const data = await batcher.fetch(key)
+  return { data, key }
+ }

[okgoodlife]

Ah, true!
At least it is true when having the key in the cache doesn't hurt, which is probably most of the time 😆