Does useResource$ re-fetch data when a lazily hydrated Qwik component resumes on the client?
0 reputation · 03 Dec 2024, 00:17 UTC
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?