getQueryDefaults doesn't merge

[TkDodo]

This was already previously discussed in:

• `setQueryDefaults`/`getQueryDefaults` and query defaults registration order #3199

and @GLabat then also added a dev-level warning if multiple defaults are found in v4:

• doc(queryClient): add dev warning with queryDefaults #3249

I don't think the current implementation is ideal. Consider the following query keys:

['todo', 'list', { done: true }]
['todo', 'list']
['todo', 'detail', { id: 1 }]
['todo', 'detail', { id: 2 }]

it would be nice if I could set different defaults for multiple layers of granularity. For example, I might want to have all todo details to have a certain staleTime, but I want everything todo related to use suspense. So I'd do:

queryClient.setQueryDefaults(['todo'], { suspense: true })
queryClient.setQueryDefaults(['todo', 'detail'], { staleTime: 5000 }]

turns out this doesn't really work because only the first matching default value is set, which would be the suspense one. It's also weird that the order of calls to setQueryDefaults matter.

What I would expect is all matching defaults to be reduced together with a simple object spread into one object. So for all my details, that would be:

{ suspense: true, staleTime: 5000 }

of course, if the same default is set on two different calls to setQueryDefaults, we would still apply it by order (last one overwriting previously set ones). It would be nice to know about specificity, but I don't think thats sensible.

Thoughts?

[DamianOsipiuk]

I think in this case we should also think about { exact: true } or something similar.
Given:

['todos']
['todos', 'settings']
['todos', 'detail', { id: 1 }]

queryClient.setQueryDefaults(['todos'], { staleTime: 5000 })
queryClient.setQueryDefaults(['todos', 'detail'], { cacheTime: 10000 }]

I do not necessarily want staleTime to be applied to detail query.
Ofc i can easily fix that by adding list to the first one, but in existing codebases it might not always be feasible.

Also given the above, should we add a possibility to not infer something less specific?
You have mentioned that specisifity is not sensible, but this will force you to model query keys around setQueryDefaults to avoid this problem.

[TkDodo]

I like the idea of having an exact: boolean second parameter, similar to what getQueryData has.

But then again, if you only want defaults for a specific key, you could also just add it to your custom hook that uses that key (there should only be one usage anyways). The defaults shine when you can set something for a group of related queries

[mattrossman]

you could also just add it to your custom hook that uses that key (there should only be one usage anyways)

I use react-query via tRPC, I don't usually make custom hooks because tRPC already handles this for me. I suppose I could create a wrapper around the tRPC autogenerated hook but no way to prevent team members from accidentally calling the non-wrapped version. I'd rather change the query defaults, but I also have global query defaults that need to cascade.

[GLabat]

I agree that the current behaviour of query defaults is strange.
Adding a warning was a quick-win to at least make dev aware of this behaviour but definitely the non-merge of defaults is counter intuitive and decreases DX.
So +1 to do something, at least the merge.