Client Lazy Data Fetching
What is the difference between
const { status, data: posts } = await useFetch('/api/posts', {
lazy: true
})
and useFetch without await?
const { status, data: posts } = useFetch('/api/posts', {
lazy: true
})
In the docs the bottom one is mentioned for loading data on SSR and lazy loading on CSR.
Trying it out it seems the await has no effect on SSR and CSR. How does Nuxt know to resolve the fetch on SSR even without the await?2 Replies
Hi @Mirko. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Great question! The difference between using await with useFetch and calling useFetch without await is subtle and relates to how Nuxt handles data fetching and navigation, especially with the lazy option.
1. useFetch with await
- With await, you are waiting for the initialization of the fetch call, but with
- On SSR, Nuxt always waits for data fetching to complete before rendering, regardless of await. - On CSR with
lazy: true, the navigation is not blocked for the data to resolve. This means that even if you use await, the data may not be immediately available on the client, and you must handle the pending state in your template.
- On the server (SSR), Nuxt will still resolve the data before rendering the page, regardless of whether you use await or not. This is because Nuxt collects all data fetching promises during SSR and waits for them to resolve before sending the HTML to the client. This mechanism works even if you don't use await in your code, as Nuxt internally tracks these promises and ensures they are resolved for SSR output. This is why "await has no effect on SSR"—Nuxt handles it for you behind the scenes.
- On the client (CSR), with lazy: true, navigation is triggered immediately, and the data will be fetched in the background. You need to handle the loading state using the status ref in your template. Awaiting useFetch in this case only ensures the call is initialized, not that the data is available yet. You should not expect the data to be ready after the await on the client with lazy mode enabled. See docs
2. useFetch without await
- Without await, you get the same result: the fetch is initialized, and you receive reactive refs for status and data. You must handle the pending state in your template.
- On SSR, Nuxt still collects and resolves the data before rendering, so the page is rendered with the data available.
- On CSR, navigation is not blocked, and data is fetched in the background.
Why does Nuxt resolve fetches on SSR even without await?
Nuxt's data fetching composables like useFetch and useAsyncData are designed to work seamlessly with SSR. When you use them in your setup function, Nuxt internally tracks all data fetching promises and ensures they are resolved before rendering the page on the server. This works regardless of whether you use await or not, because the composables return a "mixed" object: it's both a Promise and an object with reactive properties (data, status, etc.). This allows Nuxt to await all data fetching operations during SSR automatically, ensuring the HTML sent to the client is fully hydrated with data. See Stack Overflow explanation
Awaiting useLazyFetch in this mode only ensures the call is initialized. On client-side navigation, data may not be immediately available, and you should make sure to handle the pending state in your app. See docs
In summary:- On SSR, Nuxt always waits for data fetching to complete before rendering, regardless of await. - On CSR with
lazy: true, navigation is not blocked, and you must handle loading states yourself.
- Awaiting useFetch with lazy: true does not guarantee data is available on the client; it only initializes the fetch.
For more, see the official docs on useFetch, useLazyFetch, and the data fetching guide.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@356796096879656972> Kapa.ai is still learning and improving, please let me know how I did by reacting below.