Layouts and Nested Routes

Analogy categoryAnalogies

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.

tsx

// 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?

File-Based Routing

Related Study Notes in Web Development

Browse all study notes

Web Development

WebSockets Study Notes

Web Development · 30 topics

Web Development

WebAssembly Study Notes

WebAssembly · 30 topics

Web Development

gRPC Study Notes

Protocol Buffers · 30 topics

Web Development

Spring Boot Study Notes

Java · 30 topics

Web Development

Flask Study Notes

Python · 30 topics

Web Development

Django Study Notes

Python · 30 topics

Topics covered

#JavaScript#NextJsStudyNotes#WebDevelopment#LayoutsAndNestedRoutes#Layouts#Nested#Routes#Root#StudyNotes#SkillVeris

Layouts and Nested Routes