Data fetching in Nuxt 3: useFetch, useAsyncData and $fetch

In Nuxt 3 useFetch is useAsyncData with $fetch already wired in: it runs the call on the server, puts the result in the payload and reuses it during hydration, with no second request from the browser.

The normal case: page data

const { data, status, error, refresh } = await useFetch("/api/posts", {
  key: "posts",
  query: { page: 1 },
  transform: (rows) => rows.filter((row) => row.published),
});



  Loading...
  Failed: {{ error.message }}
  
    {{ post.title }}
  

await before useFetch waits for the result before rendering, so the server sends HTML that is already full. Drop the await and the same data arrives in a stream, with a visible loading state.

Sources that are not URLs

const route = useRoute();

const { data: post } = await useAsyncData(
  () => `post-${route.params.slug}`,
  () => $fetch(`/api/posts/${route.params.slug}`),
  { watch: [() => route.params.slug] },
);

The key is a function of the route: it changes with the slug and the payload stays consistent. watch repeats the call when the slug changes, and $fetch inside the function is the call itself.

Inside an event you need $fetch

async function save(title: string) {
  await $fetch("/api/posts", {
    method: "POST",
    body: { title },
  });
  await refresh();
}

Fetching composables are called during setup, not inside a click handler. In the handler use $fetch and update through the refresh the composable returns, or write the state you manage yourself.

Which one to use

Common mistakes

• A key built with Math.random(): the payload is not reused and the request fires twice.
• Reading data.value after await useAsyncData without checking error: the template reads a null value.
• Calling useFetch inside onMounted: the composable is outside the setup context.
• Putting a token in the query with useFetch: it ends up in the payload and therefore in the HTML.

The limitation to plan for

Everything useFetch and useAsyncData retrieve ends up in the payload sent to the browser. It is not a private server cache: restricted data needs an endpoint that checks the session and returns only what the user may see.

Where to go next

In the catalogue: shadcn-vue, PrimeVue and Vue Flow; data-heavy sections are in /blocks. The guides: Nuxt 3 project structure and Composition API. The comparison: the four cache layers in Next.js.