Understanding frequent network calls | TanStack | Page 1

echo crypt Jan 12, 2024, 4:25 PM

#

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...

sage oak Jan 12, 2024, 4:33 PM

#

Yes this is expected behavior in general

echo crypt Jan 12, 2024, 4:35 PM

#

would you be able to explain a little more why?

sage oak Jan 12, 2024, 4:59 PM

#

New query key = network call

echo crypt Jan 12, 2024, 5:04 PM

#

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?

left maple Jan 12, 2024, 5:12 PM

#

from what you are describing, I wouldn't expect a network call of the list just because the dialog opens

echo crypt Jan 12, 2024, 6:28 PM

#

@left maple 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

echo crypt Jan 12, 2024, 6:46 PM

#

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?

left maple Jan 12, 2024, 6:49 PM

#

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

echo crypt Jan 12, 2024, 6:51 PM

#

is one of those preferred over another?

left maple Jan 12, 2024, 6:53 PM

#

I prefer staleTime because almost everything respects staleTime. time-based caching is good

echo crypt Jan 12, 2024, 6:54 PM

#

gotcha, that makes sense. and just for my own understanding, why would it not be preferred to use .getQueryData?

left maple Jan 12, 2024, 6:56 PM

#

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 🙂

echo crypt Jan 12, 2024, 6:57 PM

#

ahhh yes, that makes a lot of sense now. thank you!!

#Understanding frequent network calls