Why does useQuery need a key? Is it possible to do without it?

[bitttttten]

I have been wondering why does useQuery actually need a key that the user needs to create? I was thinking it would be possible to make a "hash map" where the caches can be keyed by the queryFn. Would there be any issues with that? With a Map data structure, you are able to use a function as a key.

// given this
useQuery(fetchTodoList)

I was imaginging a cache implementation of:

// using typescript to hopefully help visualise the data structure
interface CacheMap {
    [key: string]: boolean
}

const cache = new Map<Function, CacheMap>()

const useQuery = (queryVariables, queryFn) => {
   const localCache = cache.get(queryFn)

   // leaving the implementation out for "stringify" just to keep psuedo-code
   const key = stringify(queryVariables)
   const hasItemInCache = localCache?.[key]

}

I was trying to check out the code and couldn't see any cases where the key sent from the user is needed.. although I am still digging through! And I feel like it would make such a great improvement to the API 🤔

[tannerlinsley]

Yep, you can easily do this like you have shown in a custom hook that wraps useQuery, or you could even experiment with the custom key serializers as well. The reason it's built this way is so that is can be flexible enough to handle use cases just like this one.

[bitttttten]

Oh nice! Yeah, I can see this easily being added in then :) Are there any downsides to doing is this way? Are there any edge cases that are avoided or solved by using the string keys as in the docs?

[tannerlinsley]

Well, the reason you have to be careful just wrapping your own solution is because you'll also have to make that same translation from function to string when using any of the queryCache methods as well to either refetch, clear, lookup, mutate etc any queries based on their keys or key roots