[@tanstack/react-query]: reference based dependencies

[justsaul]

Hi!

I'm trying to work-around limitations of how queryKeys work. However, since values of queryKey get stringified - this doesn't seem to be doable.

Lets imagine such example:

class MyFancyService {
    constructor (locale, secret, fetcher) {
        this.locale = locale
        this.secret = secret
        this.fetcher = fetcher
    }
    
    action = () => {
        return new Promise((resolve, reject) => resolve(`${this.locale}-${this.secret}`))
    }
}

const useMyFancyService = () => {
     // contextual data
     const { locale } = useLocaleStore()
     const { locale } = useSecretStore()
     const fetcher = (...props) => { return fetch(props)}

     return useMemo(() => new MyFancyService(locale, secret, fetcher), [locale, secret, fetcher])
}

And then using such service within reactQuery usually tends to look like this:

const useMyFancyQuery = () => {
     const myFancyService = useMyFancyService()
     return useQuery({
         queryKey: ['fancy-key'],
         queryFn: () => myFancyService.action(),
     })
}

Now the problem here is that I would like useMyFancyQuery to be re-evaluated given that myFancyService reference changes (meaning myFancyService.action() would re-run with new contextual values). However, this is not doable, since queryKeys don't really work as regular dependency array would (for example within useMemo hook) instead, they get stringified.

In this example, whenever fetcher dependency changes within useMyFancyService, we will re-create it. However, from stringification standpoint, we will yield with same stringified value as before. Since, functions gets ommited from stringification.

What if we were to introduce new referential based property for useQuery?

in that case we could:

const useMyFancyQuery = () => {
     const myFancyService = useMyFancyService()
     return useQuery({
         queryKey: ['fancy-key'],
         queryFn: () => myFancyService.action(),
         queryReferentialDependencies: [myFancyService]
     })
}

re-evaluation of useQuery would be done whenever queryKey or queryReferentialDependencies change.

---

Current thoughts/solutions:

• Alternatively, MyFancyService could expose it's UUID which would become part of queryKeys...
• Another alternative is to provide dependencies of MyFancyService - locale & secret as queryKeys. However, this is highly limiting factor as query becomes too coupled with service creation.
• Combining useMyFancyService and useMyFancyQuery is not doable, since in real life example useMyFancyService comes from external library.

I haven't seen any issues/suggestions regarding this, so I'm really curious on your take regarding this.

[Birkbjo]

From my limited testing, providing a service-class directly (eg. queryKey: [service] does actually work pretty well, but I guess it depends on the class you're using.

I probably would've tried to use eg. queryKeyHashFn and base it on dependencies of your service. But that would basically be the same thing as you don't want:

Another alternative is to provide dependencies of MyFancyService - locale & secret as queryKeys.

So here's an alternative idea, this might be horrible - but here goes:

const useReferentialQueryKey = (queryKey, deps) => {
  const [updateCount, setUpdateCount] = React.useState(0)

  React.useEffect(() => {
    setUpdateCount(cnt => cnt+1)
  }, deps)

  return queryKey.concat({ ref: updateCount })
}

const useMyFancyQuery = () => {
     const myFancyService = useMyFancyService()
     const serviceKey = useReferentialQueryKey(['fancy-service'], [myFancyService])
     return useQuery({
         queryKey: serviceKey
         queryFn: () => myFancyService.action(),
     })
}

[justsaul]

Yeah, regarding stringifying class instances, it depends on property types (functions to be precise) For example:

class Example {
    constructor (prop) {
        this.prop = prop
    }
}

JSON.stringify(new Example('string-value')) // '{"prop":"string-value"}'

JSON.stringify(new Example({'o-prop': 'o-prop-val'})) // '{"prop":{"o-prop":"o-prop-val"}}'

JSON.stringify(new Example(() => { return {test: 'test'}})) // '{}'

In last example, changing reference of passed argument (prop) will always yield with same stringified version of class instance. I will update example to reflect that 😅.

---

Regarding your take regarding manual track of reference changes and reflecting that within key - it would work, however, I see few drawbacks:

• we pollute query-cache with irrelevant information (same as for class instance exposing UUID);
• tracking changes of an actual promise creating function is not part of query responsibility. Ideally we would perform re-evaluation of query whenever dependency or promise creating function has changed.

[Birkbjo]

we pollute query-cache with irrelevant information (same as for class instance exposing UUID);

This is a valid argument. However I would just use queryKeyHashFn, and define your dependencies, like TkDodo says as well.
However, if you really don't want to do this, I guess you could try to use the same idea as above with queryKeyHashFn. It does seem a bit hacky though. But it would mean you don't pollute your keys directly - just the hash. But you need different hashes if the reference change...

const useReferentialQueryKeyHashFn = (deps) => {
  const [updateCount, setUpdateCount] = React.useState(0);

  React.useEffect(() => {
    setUpdateCount((cnt) => cnt + 1);
  }, deps);

  return ([key]) => { // note this would fail if your key was object...
    return key.concat(updateCount);
  };
};

[TkDodo]

// note this would fail if your key was object...

keys have to be arrays so this is fine.

I think this is a good solution / workaround 👍

[Birkbjo]

keys have to be arrays so this is fine.

I mean't if the first part of key is not a string or an array. Eg. [{ resource: '/api/todos'}].

[TkDodo]

Ah, because you destruct the key. So I'd just not do that?

return (queryKey) => {
    return queryKey.concat(updateCount);
  };

[Birkbjo]

Ah, because you destruct the key. So I'd just not do that?

I thought about that, but doesn't the function need to return the actual hashed result (eg. a string)? So in that case you would have to wrap the result in the default hashQueryKey?

[TkDodo]

keys need to be hashed so that we can persist them, which is important for a lot of things like server-side-rendering & hydration as well as persistence to external storages.

You can pass your own queryKeyHashFn, in which you have to serialize your class into some string that represents its changes. So if you put myFancyService into the QueryKey, and you know it takes locale and secret in as a relevant prop that can change, you would need to create a queryKeyHashFn that would return the stringified result of those two props.

[justsaul]

Please correct me in case I'm wrong but queryKeyHashFn in essence acts the same way, that example by @Birkbjo would. I can see few problems here:

• locale and secret are internals of promise creation, query shouldn't be concerned with that.
• why we would create new hash if only promise wrappers reference have changed?

Maybe it's just me but it feels like we're lacking stronger primitive to have finer control over when query should be re-evaluated. Just a random thought, but perhaps drawing closer parallel to react hooks could be interesting area of exploration...?

const useMyFancyQuery = () => {
     const myFancyService = useMyFancyService()
     return useQuery({
         queryKey: ['fancy-key', id],
         queryFn: () => myFancyService.action(),
     }, [id, myFancyService])
}

[TkDodo]

Just a random thought, but perhaps drawing closer parallel to react hooks could be interesting area of exploration...?

it's kind of the opposite of what we want, because it makes people think about referential stability like useEffect way too much.