setDefaultOptions -> refetchQueries race condition?
I'm trying to set a global
meta option that my queryFns will recognize and do a fetch(..., {cache: "reload"}) HTTP request.
I came up with this:
My queryFn looks like this:
So the result is that after the first refetchQueries, my queryFn gets called with meta === {} but the default options are observable and up to date already, with meta.reload == true. Only by the second refetchQueries are both meta and client.getDefaultOptions().queries.meta the same within queryFn.
I also tried it with invalidateQueries (which I looked at the code that it eventually calls refetchQueries and is also awaitable), but the behavior is the same.
Am I missing something? I did not expect it to be delayed like this. I could always use client.getDefaultOptions() in my queryFns but I'd rather figure out the root cause.2 Replies
fascinating-indigo•7mo ago
setDefaultOptions is not reactive so it doesn't affect queries that are already in use
xenial-blackOP•7mo ago
Would you recommend I use
client.getDefaultOptions().queries inside my queryFn then? just for this single meta.reload property that is, and if I have other meta options I'll keep them reactive.
Or would that cause other issues potentially?