Does useResource$ re-fetch data when a lazily hydrated Qwik component resumes on the client?

Question

I'm designing a Qwik application (assuming a recent 1.x release) where several below-the-fold components fetch data with useResource$. These components are server-rendered, so their state is serialized into the resumability snapshot, and they only activate on the client after user interaction.

My uncertainty is about what happens to the resource at that moment. If the server snapshot already contains the resolved value, I would expect no additional request. But if the snapshot is incomplete or the resource wasn't tracked during SSR, the client may issue a duplicate fetch when the component resumes. Since Qwik has no built-in cache invalidation for resources, I also can't tell whether I'm responsible for keying and deduplicating these requests myself, or whether the framework reconciles server-fetched data with client execution automatically.

My goal is a predictable data-consistency strategy: server-rendered content that doesn't trigger redundant network requests on hydration, without hand-rolling a cache layer if one isn't needed.

Specifically: under what conditions does useResource$ re-run on the client after resuming? Is there a documented way to confirm from the serialized snapshot whether a resource's value was preserved? And is an explicit cache key the intended mechanism for preventing duplicate fetches across the server/client boundary?

Tasadduq Burney · Answer

Does useResource$ Re-fetch on Resume?
No, useResource$ does not re-fetch data when a lazily hydrated component resumes on the client, provided the resource was successfully resolved during server-side rendering (SSR). Qwik serializes the resolved value directly into the HTML snapshot, allowing the client to restore the state without triggering a new network request.

How Resumability Handles Resources
In Qwik 1.x, the framework treats useResource$ as a resumable piece of state. The behavior depends entirely on the state of the resource at the moment the server finishes rendering the component:

Resolved on Server: The final value is embedded in the serialized state. Upon resumption, the client reads this value from the snapshot. No additional execution of the async function occurs.
  Pending or Failed on Server: If the resource did not resolve (e.g., due to a timeout or a thrown error during SSR), the snapshot marks the resource as pending or errored. The client will then execute the function to attempt to resolve the data.
  Client-Only Components: Components that are not rendered on the server will always trigger the fetch upon their first activation on the client.

Deduplication and Cache Keys
You do not need to hand-roll a cache layer or provide an explicit cache key specifically to prevent duplicate fetches across the server/client boundary. Qwik handles this reconciliation automatically via the resumability snapshot. However, providing a key remains useful if you want to control when the resource should re-run (e.g., when a specific dependency changes) during the client-side lifecycle.

Verification Steps
To confirm that your data is being preserved and not re-fetched, follow these steps:

Inspect the HTML Source: View the page source and locate the data-qwik-state attribute (or the internal state JSON) associated with your component. Verify that the resource's value is present in the JSON.
  Monitor Network Traffic: Open the Browser DevTools Network tab. Interact with the below-the-fold component to trigger hydration. If the resource was serialized, you will see the component activate without a corresponding XHR/Fetch request.
  Negative Test: Temporarily force the useResource$ function to throw an error or return a pending promise during SSR. Verify that the client now issues a network request upon resumption.

Assumption Note
This behavior assumes you are using a standard Qwik 1.x setup where the component is part of the SSR tree. If you are using client:only components, the server cannot serialize the resource, and a client-side fetch is mandatory.

Does useResource$ re-fetch data when a lazily hydrated Qwik component resumes on the client?

1 answer

Does useResource$ Re-fetch on Resume?

How Resumability Handles Resources

Deduplication and Cache Keys

Verification Steps

Assumption Note

Your perspective belongs here.

0 question comments