Understanding frequent network calls
I'm currently working on an application for my company, and we're using Tanstack Query, and there are some questions/concerns about the amount of network calls that happen. I was reading this section of the docs (https://tanstack.com/query/latest/docs/react/guides/important-defaults?from=reactQueryV3&original=https%3A%2F%2Ftanstack.com%2Fquery%2Fv3%2Fdocs%2Fguides%2Fimportant-defaults) and just need some clarification.
So we have a task board that uses
useInfiniteQuery to get all of the tasks. When you click on an individual task, the search params are updated to hold the id for the selected task and a modal appears that makes a call to a useQueryto get the data for it to display. Is it expected that opening this task modal would also trigger a network call for our /tasks endpoint that is called with our useInfiniteQuery for the whole task board, even though nothing about the board has been modified?Important Defaults | TanStack Query Docs
Out of the box, TanStack Query is configured with aggressive but sane defaults. Sometimes these defaults can catch new users off guard or make learning/debugging difficult if they are unknown by the user. Keep them in mind as you continue to learn and use TanStack Query:
Query instances via useQuery or useInfiniteQuery by default consider cach...
13 Replies
correct-apricot•2y ago
Yes this is expected behavior in general
wee-brownOP•2y ago
would you be able to explain a little more why?
correct-apricot•2y ago
New query key = network call
wee-brownOP•2y ago
hmm okay, so because our
useGetTask query has a query key thats like queryKey: ['tasks', id] and the useInfiniteQuery has the query key queryKey: ['tasks', status_id, type, assignedIds], it triggers the network call bc they both contain 'tasks'? if our useInfiniteQuery had a completely different queryKey like queryKey: ['allTasks'], would this not cause a new network call?like-gold•2y ago
from what you are describing, I wouldn't expect a network call of the list just because the dialog opens
wee-brownOP•2y ago
@TkDodo 🔮 huh.. okay, so this shouldn't be happening? I really can't tell what would cause this to fire another call then (and since this is proprietary code, I can't share it). I'll do some more digging and report back
ok, update! I think I figured it out. we have components living in this modal that seem to be making calls to our
useGetTasks infinite query. this is because we need to access the full list of tasks in order to link them to each other. there should be a way to do this without making another query call, right? would that be what something like queryClient.getQueryData would be used for?like-gold•2y ago
no, you can call
useGetTasks again. Just make sure to set a higher staleTime so that you can only read from the cache, or use refetchOnMount: false for this callwee-brownOP•2y ago
is one of those preferred over another?
like-gold•2y ago
I prefer
staleTime because almost everything respects staleTime. time-based caching is goodwee-brownOP•2y ago
gotcha, that makes sense. and just for my own understanding, why would it not be preferred to use
.getQueryData?like-gold•2y ago
because it's not reactive, no subscription. so your component won't re-render by itself when data changes.
it's like calling
getState() in redux instead of useSelector if that means something to you 🙂wee-brownOP•2y ago
ahhh yes, that makes a lot of sense now. thank you!!
like-gold•2y ago
it might work at first but it can lead to quite hard to debug issues