Layouts, Templates, and Nesting

## Where the root layout sits The App Router builds a page by composing layouts from the top of the `app/` directory down to the matched segment. `app/layout.tsx` is the outermost of those, so it wraps every route in the application, including error and not-found UI. Being outermost has a consequence that trips people up: it is never unmounted during client navigation, because there is no navigation that leaves it. Whatever state, subscription or provider you mount there lives for the whole session. ## The document shell In the App Router the rendered HTML document comes from your own component tree, not from a separate template file. That is why the root layout carries the requirement no nested layout has: it must render `<html>` and `<body>`. ```tsx // app/layout.tsx import type { ReactNode } from 'react'; export const metadata = { title: 'Acme' }; export default function RootLayout({ children }: { children: ReactNode }) { return ( <html lang="en"> <body>{children}</body> </html> ); } ``` A nested layout — `app/dashboard/layout.tsx` — returns a `<div>` or a fragment. If it rendered `<html>` you would get nested document elements, which is invalid HTML. The rule is easy to remember precisely because it applies to exactly one file. ## No hand-written head Because the document comes from your components, the instinct is to add a `<head>` with `<title>` and meta tags. Don't. The App Router owns the head through the metadata exports: a static `metadata` object or an async `generateMetadata` function exported from any layout or page. Next collects those down the segment tree and emits the tags. Hand-writing head elements bypasses that system and produces duplicates or tags Next later overwrites. One consequence worth knowing: metadata exports are only supported in Server Components. Since the root layout is a Server Component by default, keep it that way — adding `'use client'` at the top of the file both disables its metadata export and pulls the whole application into the client module graph. Interactive pieces belong in child components that opt into the client themselves. ## What the root layout receives A layout gets a `children` prop and, when its segment is dynamic, a `params` prop. It does **not** receive `searchParams` — only pages do. That is not an oversight: layouts are preserved across navigation and are not re-rendered when only the query string changes, so a query value handed to them could be stale by construction. If shared chrome needs the query, read it in a Client Component nested inside the layout. In Next.js 15 and later `params` is a Promise, so you `await` it in an async layout; in earlier versions it was a plain object. ## What belongs there Everything in the root layout is loaded on every route, so it deserves a stricter budget than any other file: - **Belongs:** the `<html lang>` attribute, global stylesheet import, fonts loaded through `next/font`, context providers the entire app needs, site-wide header or footer, default `metadata`. - **Does not belong:** anything only one section needs — that goes in that section's nested layout — and heavy client-side widgets, which drag their whole dependency tree into the initial payload of every page. ## How this reads in an interview The expected answer has three parts, and candidates usually give one. Say (1) it is required and wraps every route, (2) it is the only layout rendering `<html>` and `<body>`, and (3) head tags come from the metadata exports rather than a hand-written `<head>`. Adding the cost argument — everything here is on the critical path of every page — is what turns a recited rule into a demonstration that you have shipped with it.