Layouts and Nested Routes
A layout in the Next.js App Router is a component defined in a layout.tsx file that wraps a page and any nested routes beneath it, rendering shared UI like navigation bars, sidebars, or footers. Unlike a page, a layout receives a children prop representing whatever route segment is currently active, and critically, layouts persist across navigations within their scope rather than re-rendering from scratch on every route change.
Cricket analogy: A layout persisting across navigation is like a stadium's stands and floodlights staying fixed while the specific match being played changes — the surrounding structure doesn't get rebuilt for every fixture.
Root Layout
Every App Router project requires a root layout at app/layout.tsx, and it must contain the <html> and <body> tags since there is no separate _document.js file like in the Pages Router. The root layout is the ideal place for globally shared elements such as a top navigation bar, a global footer, font loading via next/font, and global metadata defaults.
Cricket analogy: The root layout requiring <html> and <body> is like an international match requiring an accredited ground with fixed dimensions before any cricket can be played there at all — a mandatory baseline structure.
// app/layout.tsx (Root layout)
import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'] });
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="en" className={inter.className}>
<body>
<header>Global Nav</header>
{children}
<footer>Global Footer</footer>
</body>
</html>
);
}
// app/dashboard/layout.tsx (Nested layout, no <html>/<body>)
export default function DashboardLayout({ children }: { children: React.ReactNode }) {
return (
<div className="dashboard-shell">
<aside>Sidebar Nav</aside>
<div className="content">{children}</div>
</div>
);
}Nested Layouts and Templates
Any folder within app/ can define its own layout.tsx, and nested layouts wrap only the routes beneath that folder, composing with parent layouts rather than replacing them — a request to /dashboard/settings renders the root layout, then the dashboard layout, then the settings page, nested in that order. A related but distinct file, template.tsx, looks similar but creates a new instance and re-runs effects on every navigation instead of persisting, useful for enter/exit animations or resetting local state.
Cricket analogy: Nested layouts composing rather than replacing is like an ICC tournament nested inside a national board's overall governance, both layers of rules applying simultaneously to a single match.
Because layouts persist across navigations, client-side state inside them — like a sidebar's scroll position or an open/closed accordion — is preserved automatically when a user navigates between sibling pages that share the same layout, with no extra state management required.
Composing Multiple Layouts
Layouts compose hierarchically based on folder nesting: app/layout.tsx wraps everything, app/dashboard/layout.tsx wraps everything under /dashboard, and app/dashboard/settings/layout.tsx would wrap only /dashboard/settings and its children. This lets shared UI live at the appropriate scope — a global header at the root, a dashboard-specific sidebar one level down, and a settings-specific tab bar one level further, each independent and reusable.
Cricket analogy: Layout hierarchy scoping shared UI is like ICC rules governing all cricket, BCCI rules governing Indian domestic cricket specifically, and IPL franchise rules applying only within that specific league — each nested inside the last.
A layout cannot directly read the full dynamic route params of a page nested deep beneath it unless those params belong to a segment the layout itself is part of, and layouts render on the server by default, so calling client-only hooks like usePathname requires explicitly marking the layout with "use client", which then opts that whole subtree out of some server-rendering benefits.
- A layout.tsx file wraps a page and any nested routes beneath it, receiving a children prop.
- Layouts persist across navigation within their scope instead of re-rendering from scratch.
- The root layout at app/layout.tsx is required and must include <html> and <body>.
- template.tsx looks similar to a layout but creates a fresh instance on every navigation.
- Nested layout.tsx files compose hierarchically based on folder depth.
- Persisted layout state, like scroll position, survives navigation between sibling routes automatically.
- Client-only hooks require marking a layout with "use client", which affects the whole subtree.
Practice what you learned
1. What prop does a layout.tsx component receive to render the active route content?
2. What must the root layout at app/layout.tsx contain that other nested layouts must not?
3. How does template.tsx differ from layout.tsx in behavior?
4. What happens to a sidebar's scroll position when navigating between two sibling pages that share the same layout?
5. What is required to use a client-only hook like usePathname inside a layout?
Was this page helpful?
You May Also Like
File-Based Routing
How Next.js derives an application's routes automatically from the folder structure inside the app directory, including dynamic segments and navigation.
The App Router vs Pages Router
A comparison of Next.js's two routing systems — the legacy Pages Router and the modern App Router built on React Server Components.
Creating a Next.js Project
How to scaffold a new Next.js application with create-next-app, understand its generated project structure, and run the development server.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics