useFetch with refresh() or useAsyncData with a custom key: which gives better control over stale cached data in Nuxt 3?

Answer

For independent invalidation of the same endpoint across routes, useAsyncData with an explicit, route‑specific key is the better choice. It lets each route own its cache entry so calling refresh() updates only that entry without triggering refetches elsewhere.

Why this works

1. useFetch is a thin wrapper that automatically builds a cache key from the request URL and options. All components that call the same URL share the same key, so a refresh() invalidates the shared entry and causes every route to refetch.
2. useAsyncData lets you supply any string as the key. By incorporating route information (e.g., the current path, a route‑unique ID, or a combination of path and query) you create distinct cache entries for each route while still benefiting from SSR hydration.
3. The explicit key does not change how data is hydrated: both composables serialize the server‑side result into the initial payload and rehydrate it on the client using the same mechanism. The key only determines which cache entry is read or written.

Steps to implement per‑route invalidation

1. In each route‑specific component, call useAsyncData with a key that includes the route:

const { data, refresh } = await useAsyncData(
  `my-data-${useRoute().path}`, // explicit, route‑unique key
  () => $fetch('/api/my-data')
)

2. Expose refresh (e.g., via a button) to invalidate only that route’s cache:

<button @click="refresh">Reload data</button>

3. When refresh() is called, Nuxt updates the cache entry for that key only; other routes retain their existing entries and do not issue a second network request.

Verifying hydration without duplicate requests

1. Open Nuxt DevTools → Network tab.
2. Navigate to a page that uses the composable.
3. Confirm that after the initial page load no additional XHR/fetch request appears for the same endpoint when the component mounts on the client.
4. Switch to the State tab, locate the entry under your custom key, and verify its value matches the server‑rendered payload.
5. Trigger refresh() and observe that only the route‑specific entry updates in the State tab and that no duplicate request is fired for other routes using the same endpoint.