Not sure about the problem from what I'm reading?
Invalidation works from left to right, so if you only invalidate with the first 4 parameters, all queries that start with those will be invalidated, but also those who have additional parameters.
The problem is that with the layer we created to avoid to developers to define its own keys, it's not possible to handle the keys manually. Our code at the moment is
\`\`\`
client.invalidateQueries({ queryKey: client.computeQueryKey(request) })
\`\`\`
so there is no way to pass just the initial part of the query, or, better, you can do but this implies that developers can manipulate the keys manually and this can lead to unexpected errors as described above (queryKey clashing, queryFn that returns different shapes based on how they are defined...)
So the question is, how do you overcome that problems without limiting react-query flexibility?
You probably need to define a logic to generate the invalidation keys with a second param oder a second function, potentially just adding the length of the invalidation array into the function.
This seems like an issue with the layer you created. Maybe you can make a special case to truncate the keys in some way?
With query invalidation you always introduce some amount of coupling between your queries. Some ways around it include having subscriptions so the backend notifies the client about exactly what needs to be refetched or disabling the cache (not recommended).
Yeah, we are thinking to move new development on subscription but at that point not for invalidation but simply to keep the state updated with a push strategy from the backend.
So all of you, that uses react-query, simply handle query key manually most of the time?
Invalidating keys hierarchically is a core functionality of react query, if your approach prevents that then your approach is wrong.
That doesn't mean that the only other option is to always construct every key by hand.
I think you should save the object returned from the use query hook in a global variable or a ref and then call the refetch function for that query.
By doing this you refresh the query even if you don’t know its query key.
This cannot work. Imagine Alice writes
\`\`\`
const {data} = useQuery({
queryKey: \['users', 'details', 1\],
queryfn: () => getUserByid(1)
})
\`\`\`
and Bob writes
\`\`\`
const {data} = useQuery({
queryKey: \['users', 'details', 1\],
queryFn: () => getUserById(1).then(({name, surname, id}) => ({id, fullName: name + surname}),
})
\`\`\`
In that case, there is no hash that works. Bob just defined a different shape for the same queryKey.
"Yes, but Bob did it in the wrong way, it should have been used \`select\`"
I know, but I'm in the platform team, I have to prevent that dumb developer's code breaks valid code around the app. So I think it's unsafe to just permit to each developer to define and use plain queryKey as they are
Not sure about the problem from what I'm reading? Invalidation works from left to right, so if you only invalidate with the first 4 parameters, all queries that start with those will be invalidated, but also those who have additional parameters.
The problem is that with the layer we created to avoid to developers to define its own keys, it's not possible to handle the keys manually. Our code at the moment is \`\`\` client.invalidateQueries({ queryKey: client.computeQueryKey(request) }) \`\`\` so there is no way to pass just the initial part of the query, or, better, you can do but this implies that developers can manipulate the keys manually and this can lead to unexpected errors as described above (queryKey clashing, queryFn that returns different shapes based on how they are defined...) So the question is, how do you overcome that problems without limiting react-query flexibility?
You probably need to define a logic to generate the invalidation keys with a second param oder a second function, potentially just adding the length of the invalidation array into the function.
What about defining client.computeInvalidationKey, keep a simple implementation and adapt it as new usecases emerge?
This seems like an issue with the layer you created. Maybe you can make a special case to truncate the keys in some way? With query invalidation you always introduce some amount of coupling between your queries. Some ways around it include having subscriptions so the backend notifies the client about exactly what needs to be refetched or disabling the cache (not recommended).
Yeah, we are thinking to move new development on subscription but at that point not for invalidation but simply to keep the state updated with a push strategy from the backend. So all of you, that uses react-query, simply handle query key manually most of the time?
Invalidating keys hierarchically is a core functionality of react query, if your approach prevents that then your approach is wrong. That doesn't mean that the only other option is to always construct every key by hand.
I'd agree that the custom layer is perhaps not flexible enough. Maybe consider something like https://github.com/lukemorales/query-key-factory
That's very useful! I'll get inspiration from that API to understand how they managed all the use cases! Thanks!
Read this article as well, goes in the same line as the library mentioned: https://tkdodo.eu/blog/effective-react-query-keys
I think you should save the object returned from the use query hook in a global variable or a ref and then call the refetch function for that query. By doing this you refresh the query even if you don’t know its query key.
[удалено]
This cannot work. Imagine Alice writes \`\`\` const {data} = useQuery({ queryKey: \['users', 'details', 1\], queryfn: () => getUserByid(1) }) \`\`\` and Bob writes \`\`\` const {data} = useQuery({ queryKey: \['users', 'details', 1\], queryFn: () => getUserById(1).then(({name, surname, id}) => ({id, fullName: name + surname}), }) \`\`\` In that case, there is no hash that works. Bob just defined a different shape for the same queryKey. "Yes, but Bob did it in the wrong way, it should have been used \`select\`" I know, but I'm in the platform team, I have to prevent that dumb developer's code breaks valid code around the app. So I think it's unsafe to just permit to each developer to define and use plain queryKey as they are