Icustom hook is mostly pointless in tRPC unless you're doing a lot of weird options or something with query consistently or something. TRPC handles creation of the query keys and such (in vanilla tanstack query you have to manually create keys from query inputs so the custom hook is desirable).
As far as how fetching works, this is a tanstack query thing. It works like this:
When a new component mounts that subscribes to some query:
Note that by default
In your case, the data is fetched once. The query cache for each query input is global, so each component is seeing the same data object at all times.
cacheTime => "How long to keep this stuff in the cache when there is no component subscribed to that cache"
staleTime => "When do we want to trigger refetches on new component subscriber"
As far as how fetching works, this is a tanstack query thing. It works like this:
When a new component mounts that subscribes to some query:
- it will fetch the data if it hasn't been fetched
- if it has been fetched and is still in the cache (based on cache time), it will check if the query is "stale" based on stale time. If it is stale, it will refetch the data in the background and update it (in the background meaning it shows previous data while the new data is fetched)
- if it's not stale it won't refetch
Note that by default
staleTimeIn your case, the data is fetched once. The query cache for each query input is global, so each component is seeing the same data object at all times.
cacheTime => "How long to keep this stuff in the cache when there is no component subscribed to that cache"
staleTime => "When do we want to trigger refetches on new component subscriber"
IPersonally I pass the data down from the top component usually. With your approach, you're potentially having to handle loading states at multiple levels which is more work and possibly can lead to a jankier UI. I do something like:
Where
The nice thing about this approach is that
Where
<QuerySuspended/> shows some loading state when a query is still loading, and can also handle error states.The nice thing about this approach is that
FooBarIt's okay to call useQuery on multiple levels though, doesn't necessarily have to be at the top. Just do what's easiest for your situation, just be careful of request waterfalls if you're doing conditional rendering