First time a queryKey is intialised in a useQuery hook takes 500ms.
Description
We're experiencing a consistent 500-1000ms delay the first time we call useQuery() for with a trpc key (and only the first time for each new query key), even before any network request is initiated.
Is setting up the observer and cache for an individual query supposed to be this expensive? We've done a ton of experiments to isolate the cause (and I've read all of @TkDodo 🔮 great essays on RQ), and are stuck here.
Observed Behaviour
We have an app that changes an "activeConversationId". Every time this conversationId changes, a 500ms js thread blocking processing occurs from react query.
1. The first time, and only the first time a new conversationId is passed in, there's a ~500-1000ms blocker. So if I select a conversationId, and select a different one, and come back, this won't happen. This means it's not the rendering itself.
2. Not the network call or downstream result of data changing. Even if I set enabled to "false" permanently, this still happens.
3a. NOT tRPC overhead: Even if I don't use TRPC (we suspected trpc runtime compilation) and use direct queryFn, this still happens.
3b. NOT query key complexity: Tested with simple flat keys like ['simple', id] - still slow Bypassed tRPC's queryOptions() - still slow
4. NOT cache lookup: Direct getQueryData() calls are instant (~1ms)
Code for query
const getConversationQuery = useQuery(
trpc.crm.getConversation.queryOptions(
{
id: conversationId!,
},
{
enabled: !!conversationId && !shouldLoad,
staleTime: 2 60 1000,
gcTime: 24 60 60 * 1000,
notifyOnChangeProps: ['data', 'error'],
placeholderData: (previousData) => previousData,
initialDataUpdatedAt: 0,
},
),
);
);
We're experiencing a consistent 500-1000ms delay the first time we call useQuery() for with a trpc key (and only the first time for each new query key), even before any network request is initiated.
Is setting up the observer and cache for an individual query supposed to be this expensive? We've done a ton of experiments to isolate the cause (and I've read all of @TkDodo 🔮 great essays on RQ), and are stuck here.
Observed Behaviour
We have an app that changes an "activeConversationId". Every time this conversationId changes, a 500ms js thread blocking processing occurs from react query.
1. The first time, and only the first time a new conversationId is passed in, there's a ~500-1000ms blocker. So if I select a conversationId, and select a different one, and come back, this won't happen. This means it's not the rendering itself.
2. Not the network call or downstream result of data changing. Even if I set enabled to "false" permanently, this still happens.
3a. NOT tRPC overhead: Even if I don't use TRPC (we suspected trpc runtime compilation) and use direct queryFn, this still happens.
3b. NOT query key complexity: Tested with simple flat keys like ['simple', id] - still slow Bypassed tRPC's queryOptions() - still slow
4. NOT cache lookup: Direct getQueryData() calls are instant (~1ms)
Code for query
const getConversationQuery = useQuery(
trpc.crm.getConversation.queryOptions(
{
id: conversationId!,
},
{
enabled: !!conversationId && !shouldLoad,
staleTime: 2 60 1000,
gcTime: 24 60 60 * 1000,
notifyOnChangeProps: ['data', 'error'],
placeholderData: (previousData) => previousData,
initialDataUpdatedAt: 0,
},
),
);
);
