Nuxt 3 useFetch and Client-Side Hydration: Managing State Synchronization

Direct answer

Nuxt 3 does not merge an immediate refresh with the serialized server payload. refresh is imperative: it starts a new client request, sets the async state to pending, and replaces the keyed state when the response arrives. If called before or during hydration, it can duplicate the server fetch and briefly overwrite hydrated data with a pending state before the new response resolves.

Unique keys add only a small string and registry overhead. Payload growth is dominated by serializing every resolved useAsyncData result, so cost scales with the number of concurrent calls and their response sizes, not merely with key uniqueness.

Confirmed behavior

• useFetch is layered over useAsyncData.
• useAsyncData accepts an explicit key and serializes the resolved result into the SSR payload.
• The client hydrates the same key and skips the fetch while payload data is present.
• refresh replaces state rather than merging it with the payload.
• Dynamic or per-render keys break server-client hydration matching and can cause duplicate fetches or state collisions.

Likely explanation and uncertainty

Calling refresh immediately in setup() can race with hydration because the client has not yet taken ownership of the keyed state. Calling it in onMounted() usually starts from hydrated state, sets pending to true, fetches, then updates data or error. Exact pending timing and duplicate-request suppression depend on the Nuxt 3 minor version, so treat version-specific race behavior as unverified.

Steps for this case

1. Use static, deterministic keys for every useFetch or useAsyncData call. Do not generate keys from random values, timestamps, or request-specific IDs.
2. Avoid calling refresh in setup() before hydration. Use onMounted() or guard the call with a hydration-aware condition if immediate revalidation is required.
3. Expect a second network request and temporary pending state when refreshing immediately after hydration; the response replaces, not merges with, the hydrated payload.
4. Limit concurrent keyed calls on one page. Paginate or lazy-load heavy data instead of creating many large useAsyncData entries.

Verification

• Inspect page source and DevTools Network: confirm the serialized payload is present and no same-key fetch occurs until refresh is invoked.
• Call refresh in onMounted() and observe pending becoming true, a second request appearing, and the response replacing the hydrated payload.
• Create a test route with increasing numbers and sizes of useAsyncData results and compare HTML/payload size to confirm growth tracks serialized data more than key strings.

Assumption: standard Nuxt 3 SSR with default payload serialization. Behavior may differ with ssr: false, prerendered routes, or useFetch({ server: false }).

Missing diagnostic detail: Which Nuxt 3 minor version are you running? Refresh/hydration race handling may differ between releases, and the version changes whether an immediate refresh in setup() is suppressed or races with hydration.