Next.js

app/blog/[slug]/page.tsx serves every single-segment URL under /blog, such as /blog/hello and /blog/42. Next passes the matched text to the page in the params prop as { slug: 'hello' }; since Next 15 params is a Promise, so await it.

In the Next.js App Router, folders only define URL segments. A segment becomes reachable only when it contains a page file that default-exports a component (or a route file for an API endpoint). Every other file in the folder is just colocated code.

A parenthesised folder is a route group: Next omits it from the URL, so app/(marketing)/about/page.tsx still serves /about. Groups let you organise route files and scope a layout to a subset of routes without adding a URL segment.

The root layout is required, wraps every route in the app, and is the only layout that renders the <html> and <body> tags. Nested layouts render plain markup inside it and apply only to their own segment and below.

Link performs a client-side navigation: Next fetches only the changed route's React Server Component payload and swaps it in, keeping the running app alive. A plain anchor triggers a full document load that discards everything.

A prerendered route fetches its data once during the production build and serves the same stored HTML to every visitor. A per-request route re-runs that code on each visit, so each visitor gets markup built from data read at that moment.

Calling a Dynamic API — cookies(), headers(), draftMode() from next/headers, connection() from next/server, or reading a page's searchParams prop — opts the entire route out of prerendering, so Next.js renders it per request.

Next.js wraps that segment's page.tsx and everything below it in a Suspense boundary whose fallback is loading.tsx's default export. The layout above stays on screen, and the fallback also appears instantly on client navigation into the route.

Prerender the landing page at build time, give the news index a short revalidation window so it regenerates roughly every minute, and render the dashboard per request because its output depends on who is asking. The driver is whether output varies per request, then how stale it may be.

Next.js decides static versus dynamic per route, and a route is the composition of the root layout plus every nested layout and the page. The root layout is part of every route, so its cookies() call opts them all out of prerendering.

None of it. A library imported only by a Server Component runs at render time on the server, so the browser downloads zero bytes of it — only the rendered output, as HTML on the first load and as an RSC payload on client navigation.

app/orders/page.tsx runs only on the server, so it awaits the query and renders the rows itself. The API route, the browser fetch, and the useEffect loading and error state all disappear. The browser receives rendered markup plus the RSC payload, never the query.

Only components that need browser behaviour: React state or effect hooks, DOM event handler props such as onClick, or browser APIs like window and localStorage. Everything else — markup, layout, data fetching — stays a Server Component with no directive.

No. Only the provider module and its own imports become client code. The pages arrive as the layout's children prop — created by the Server Component layout, rendered on the server, and handed to the provider as an already-rendered slot.

Two things reach the browser: the markup the Server Component rendered, and a verbatim copy of the props handed to the Client Component. The other 28 columns stay on the server. Verify by searching the page source for a value you never passed.

Only the form using the action prop still submits. Next renders it as an ordinary POST form carrying the action's identity in hidden fields, so the browser can submit it natively. An onSubmit handler cannot run until JavaScript loads and hydrates the page.

formData.get('email') returns FormDataEntryValue | null — a string, a File, or null if the field was absent. The FormData type annotation is erased at runtime and the body is whatever the caller posted, so the action must parse and validate before using the value.

'use server' marks a function as a server function that client code may call over the network — Next turns it into an RPC entry point. It does not make anything a Server Component; App Router components already run on the server by default.

React intercepts the submit, packs the named form controls into FormData, and POSTs it to the current URL, naming the action to run. Next executes the function on the server and returns an RSC payload that the router merges into the live page.

revalidatePath keys on a route path and invalidates what that route cached; revalidateTag keys on a label you attached to the reads themselves, for example fetch(url, { next: { tags: ['posts'] } }). Use paths when you know the affected route, tags when the same data appears on many routes.

It is a Route Segment Config export that forces the route to be rendered on the server for every request instead of being prerendered, so its HTML is never served out of Next's Full Route Cache.

No scheduler is involved. The number is a staleness window in seconds: after 3600 seconds the cached page is merely marked stale, and only the next incoming request for that route causes Next.js to regenerate it.

Passing cache: 'force-cache' stores that fetch's response in Next's server-side Data Cache so later requests reuse it instead of calling the origin. In Next 15 and 16 that is not the default: a bare fetch is uncached.

The 60 seconds belongs to that one Data Cache entry — the one keyed from that URL and those options — not to the component, the page, or any other fetch. Supplying it also opts the fetch into caching.

Four layers: Request Memoization (one render pass, server memory), the Data Cache (persistent server store of fetch results), the Full Route Cache (prerendered route output on the server), and the Router Cache (visited segments in browser memory for the session).

Next.js reads a single middleware file at the project root, next to app/ (or inside src/). Exporting config.matcher restricts which request paths invoke it; with no matcher, the middleware function runs for every request the app serves.

NextResponse.rewrite serves a different route internally: the browser keeps the original URL and makes one request. NextResponse.redirect returns a 3xx with a Location header, so the browser makes a second request and the address bar changes.

A route.ts file turns its folder's path into an HTTP endpoint. You export one async function per HTTP method, named exactly GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS, and Next.js answers 405 Method Not Allowed for any method you did not export.

It proves only that the request carried a cookie with that name — any client can send one. It does not show the session is valid, unexpired, unrevoked, or entitled to the data, so verification has to happen where the data is read.

Who calls the code decides. Middleware handles cross-cutting work on every matched request before routing; a route handler is a public HTTP endpoint for callers outside your app; a Server Action is an internal mutation invoked by your own UI.

Nothing to configure: Next.js code-splits per route automatically, so visiting /dashboard does not download /settings' client code. next/dynamic splits inside a route, deferring a heavy component until it is actually rendered or needed.

next/font/google downloads the font files at build time and serves them from your own origin, so the browser never contacts Google. The build generates the @font-face CSS, and the extra DNS, TLS and stylesheet round trips disappear.

next/image generates a responsive srcset, negotiates a modern format such as WebP or AVIF, lazy-loads by default, and requires intrinsic dimensions so the browser can reserve layout space before the bytes arrive, which prevents layout shift.

With ssr: false, Next.js skips the component during server rendering and mounts it only in the browser after hydration, rendering the loading fallback in its place meanwhile. The App Router rejects the option in a Server Component because opting out of server rendering is a client-side decision.

It emits a self-contained .next/standalone folder with a server.js and only the traced node_modules the server needs, so the image runs node server.js without the full project. It does not include public or .next/static — copy those in yourself.