Should we declare class instances queryKey?

[lisherwin]

Hi React Query community!

I have a question about queryKey best practices when class instances are used within queryFns. Suppose I have this useQuery whose queryFn fetches from storage:

export function useMap(storage: Storage): UseQueryResult<SomeObject, unknown> { // where storage is a class instance.
  return useQuery({
    queryKey: ["scope"], // React Query ESLint plugin tells me storage should be declared in queryKey.
    queryFn: async () => {
      const map = (await getMapFromStorage(storage)) ?? {};
      return map;
    }
  });
}

While it is true that storage could change implementation under the hood when its own parameters change, its accepted in our codebase as a static instance we use to reference persisted storage values (and I feel that this would be true for many codebases as well). However, ESLint tells us that the class instance should be declared within the queryKey.

I've also seen this discussion suggesting that we can declare a queryKeyHashFn to generate a hashed string from a non-serializable query key. However, it is safe to assume that the storage instance is static and it feels unnecessary to populate our query cache with information about this storage instance (and even error prone since we're now adding manually written serialization logic).

Would it be safe to ignore class instance references in queryKey? If so, are there best practices around what we can avoid declaring in query keys? Would it even make sense to update the ESLint plugin to ignore class references?

Sandbox: https://codesandbox.io/s/react-query-object-keys-forked-j4n59q?file=/src/useMap.ts

Thanks in advnace!

[TkDodo]

I think what we wanted to come up with is an allowList to specifically exclude certain names from the lint rule, for this exact reason. We already allow queryClient to be used inside the queryFn without the linter complaining.

@Newbie012 is the allowList option still something you would consider adding?

[Newbie012]

Sure why not

[lisherwin]

IMO, I almost feel like the ESLint should ignore class instances altogether and maybe add opting in as an option. I can't think of many cases where we'd want to serialize a class instance for a query key, but I might have a biased/skewed perspective on how others use query keys.