T
TanStack•2y ago
exotic-emerald

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
other-emerald
other-emerald•2y ago
Yes this is expected behavior in general
exotic-emerald
exotic-emeraldOP•2y ago
would you be able to explain a little more why?
other-emerald
other-emerald•2y ago
New query key = network call
exotic-emerald
exotic-emeraldOP•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?
harsh-harlequin
harsh-harlequin•2y ago
from what you are describing, I wouldn't expect a network call of the list just because the dialog opens
exotic-emerald
exotic-emeraldOP•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?
harsh-harlequin
harsh-harlequin•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 call
exotic-emerald
exotic-emeraldOP•2y ago
is one of those preferred over another?
harsh-harlequin
harsh-harlequin•2y ago
I prefer staleTime because almost everything respects staleTime. time-based caching is good
exotic-emerald
exotic-emeraldOP•2y ago
gotcha, that makes sense. and just for my own understanding, why would it not be preferred to use .getQueryData?
harsh-harlequin
harsh-harlequin•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 🙂
exotic-emerald
exotic-emeraldOP•2y ago
ahhh yes, that makes a lot of sense now. thank you!!
harsh-harlequin
harsh-harlequin•2y ago
it might work at first but it can lead to quite hard to debug issues

Did you find this page helpful?