QueryClient support defaultOptions queryKey for set token to queryKey?

[vaynevayne]

I need to put the token in all the queryKey, is there anything like the middleware of swr?

[vaynevayne]

Is this usage correct?

import { useQueryClient, hashKey } from '@tanstack/react-query'
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      gcTime: 1000 * 60 * 60 * 24, // 24 hours
      queryKeyHashFn: queryKey => {
        const {  token } = useLocalStore.getState()
        return hashKey(queryKey.concat(token))
      },
    },
  },
})

[TkDodo]

you can do that, I’m just wondering why you would want a token (I assume an access token?) to be part of the queryKey? That means when the token changes, you’ll get a new cache entry that won’t know about data from the previous query with the old token, which usually isn’t what you want with access tokens?

[vaynevayne]

The next user should not see the information of the previous user

[976520]

@vaynevayne
If I understood correctly, you’re including the token in the queryKey to prevent cached data from a previous user being shown after a user switch — basically to isolate or invalidate queries on user change. That makes sense. 😁

That said, adding the token to the queryKey (as in your example using a custom queryKeyHashFn) might lead to some subtle cache duplication issues, since the token gets hashed in and may not be obvious from the key structure. If you include the token in the queryKey, there's a risk that the auth token could get exposed externally through browser devtools, error reporting tools, etc.

queryKey is an identifier that defines "what data to fetch." But the token is an authentication state, which is a completely separate concept from data identifiers. I think when the auth state changes and the queryKey structure changes with it, it can create confusion between the code's intent and the actual query cache behavior. If you include the token in the queryKey, the same data gets cached with completely different keys for each user(= token).

For example, even if all users send the same ['userProfile'] query, with different tokens you'd end up with multiple duplicate caches like ['userProfile', tokenA], ['userProfile', tokenB]. While this does meet the requirements, it can lead to memory waste.

For this kind of use case, the more typical approach and what the maintainers seem to recommend would be to avoid putting the token directly in the queryKey,
instead:
• Call queryClient.clear() on logout to wipe the whole cache
• Use invalidateQueries() on token change to selectively refetch the relevant queries.

Another option you could explore is creating a new QueryClient instance per user, and swapping it out when the user changes like ,

const userSpecificQueryClient = new QueryClient();

<QueryClientProvider client={userSpecificQueryClient}>
  ...
</QueryClientProvider>

Also if your fetchers pull the token from somewhere like a global store or context, and you call invalidateQueries() when the token changes, you can refresh the queries without needing to tie the token into the key at all. (and that generally avoids weird side effects maybe...)

I ended up writing a bit more than necessary, but I hope it helps 😘