T
TanStack2mo ago
adverse-sapphire

Minimizing QueryKey Size with Dependent Queries

Hello, I have a dependent query that relies on another query, so the eslint exhaustive-deps rule tells me to add that result to my new query's key. However, that is a very large array of objects when serialized, so my queryKey is gigantic, and really makes the DevTools hard to work with. Can I instead just use the query.lastUpdated property? That seems to update and invalidate my dependent query whenever the primary query changes (though I understand it happens even if the data hasn't changed, that's OK in this scenario) Just wondering if there's some hidden dragon I'm not thinking about here, or if there's a better way without ending up with a massive query key for dependent queries, or some way to make the display in the tanstack devtools not be unwieldly. The documentation is silent on this in regards to dependent queries, all the examples are simple things where the depending query is a simple object, not a complex one. Alternatively, is there a way to emit a custom "key" property that, for instance, is just the list of IDs of the objects or only the relevant data I care about changing that should trigger an update, while still retaining the main data? Or conversely, on my dependent query, a way to analyze the depending data object to determine if a refresh is required other than just simply if anything changed?
1 Reply
extended-salmon
extended-salmon2mo ago
if you need all those objects inside the queryFn then adding them to the key is correct. With the timestamp you get a new query after every fetch even if the objects are the same because nothing changed on the server, so I wouldn't do that
Alternatively, is there a way to emit a custom "key" property that
you can provide a custom "queryKeyHashFn"

Did you find this page helpful?