From your Getting started II note: routing, SEO, data fetching, state and errors.
<NuxtLink> renders an <a href>; once hydrated, the router intercepts the click, runs validation and route middleware, loads the page chunk (code-split, usually prefetched), updates the URL with the History API, and <NuxtPage> (<RouterView> in <Suspense>) keeps the old page until awaited data is ready.app/middleware/, global, named or inline) runs around navigation, on the server for the first load and in the browser after that; it's UX, not security. Server middleware (server/middleware/) runs in Nitro for every request.$fetch for event handlers and server code; useAsyncData(key, fn) for any async work the page renders; useFetch(url) = useAsyncData + $fetch with a generated key, typed routes and cookie forwarding. Same return values and options.useFetch's generated key includes the call's location, so two components don't share; give an explicit key to share (useNuxtData reads it).lazy: true don't block client navigation but are still in the server HTML; server: false skips the server render entirely.useFetch forwards the user's headers to your own API during SSR (useRequestFetch); useAsyncData + $fetch doesn't; external APIs get nothing; Set-Cookie back to the browser is manual (appendResponseHeader).useState: per request on the server, per page load in the browser, travels in the payload, must be serialisable, not persistent (use useCookie).createError({ status, statusText }); fatal during SSR, non-fatal in the browser unless fatal: true; error.vue replaces the app, clearError({ redirect }) leaves it; <NuxtErrorBoundary> for local errors.app.head defaults, useHead for anything in <head>, useSeoMeta for typed meta tags; they must be in the server HTML."Lazy: request is called during onMounted": that's what happens in the browser. During SSR the render still waits for a lazy request, so the data is in the HTML and in the payload; lazy only stops client-side navigation from waiting. To skip the server, use server: false.
"useAsyncData — wrapper around $fetch": it's the other way round. useAsyncData runs whatever async function you give it, with or without $fetch; useFetch is the wrapper, useAsyncData plus $fetch with a generated key.
"Creates the url as a shallowRef and intercepts any change on it": the link component intercepts the click and calls router.push, which runs guards, loads the page and then updates the URL with history.pushState. currentRoute is the shallow ref that <RouterView> renders from; back and forward arrive through the popstate event.
useFetch, not awaited, lazy: true and server: false. Check the page source after a hard reload and the network panel during client navigation for each.useFetch('/api/cart') from two components, watch two requests, then add the same key to both.createError({ status: 404 }) once in a page's setup and once in a click handler; then add fatal: true to the second."useFetch for data the page renders from one URL: it runs on the server, puts the result in the payload, forwards cookies to my own API and is typed from the server route. useAsyncData for anything async that isn't one URL, with an explicit key. $fetch for actions like form submits and for server code; in setup it would fetch twice."
"Both stop the request from blocking, in different places. lazy is about client-side navigation: the new page shows at once with a loading state, but during SSR the data is still fetched and in the HTML. server: false skips the server render, so the data is fetched only in the browser and isn't in the HTML, which suits comments, recommendations or live stock, not anything SEO needs."
Nothing yet. Notes filed here show up on this page and the section overview.
Rendering and lifecycle
CSR, SSR and prerendering, route rules (swr, isr, prerender, ssr false, cors, proxy), data baked into prerendered pages, CORS, the order things run on the server and in the browser, and server components with nuxt-client and slots.
The Nitro server
h3, unstorage and unenv, server routes and their types, validated input, event.$fetch, server middleware versus Nitro plugins and their hooks, response fragmentation with render:html and render:response, the three ways to cache, varies, and a reusable authenticated handler.