## What is a Layout in Next.js? Imagine your application has the same: - Navbar - Sidebar - Header - Footer - Navigation on multiple pages. You *could* copy them into every `page.jsx`. But then one day you change the navbar... and suddenly you're editing 27 files wondering how life reached this point. 💀 [Next.js](/courses/nextjs) solves this with **layouts**. A: ```text layout.jsx ``` file creates shared UI that wraps pages and nested routes inside a particular part of your application. Think of a layout as the **shell of your page**. For example: ```text Navbar --------------------- | | | Page Content | | | --------------------- Footer ``` The Navbar and Footer belong to the layout. The middle content changes depending on which page the user visits. --- ## The Basic Layout Idea Suppose your project looks like this: ```text src/app/ ├── layout.jsx ├── page.jsx ├── about/ │ └── page.jsx └── contact/ └── page.jsx ``` The root: ```text layout.jsx ``` wraps all these pages. Conceptually: ```text Root Layout ├── Home Page ├── About Page └── Contact Page ``` When the user moves between these routes, [Next.js](/courses/nextjs) can reuse the shared layout instead of rebuilding the entire UI. This behavior is called **partial rendering**. --- ## Why Layouts Matter Suppose your layout contains: ```text Navbar Sidebar Page Footer ``` and the user navigates from: ```text /dashboard ``` to: ```text /dashboard/settings ``` Next.js doesn't need to replace the entire dashboard shell. Instead, the experience is closer to: ```text Navbar ← stays Sidebar ← stays Dashboard ← replaced ``` becoming: ```text Navbar ← stays Sidebar ← stays Settings ← new page ``` Only the part that actually changed needs to update. That's one reason navigation in the [App Router](/courses/nextjs) can feel very app-like. > **Definition: Layout** > > A layout is a [React](/courses/reactjs) component that provides shared UI for pages and nested routes. During client-side navigation, shared layouts are reused while the changing route content updates. --- # The Root Layout Every App Router application needs a **root layout**. If you're using the `src/` directory, it normally lives here: ```text src/app/layout.jsx ``` A basic root layout might look like this: ```jsx import "./globals.css" export const metadata = { title: "My App", description: "My awesome Next.js app", } export default function RootLayout({ children }) { return ( {children} ) } ``` The root layout is special because it defines the application's: ```html ``` and: ```html ``` elements. --- ## Adding Global UI You can put UI inside the root layout that should appear across your application. For example: ```jsx import "./globals.css" export const metadata = { title: "My App", description: "My awesome Next.js app", } export default function RootLayout({ children }) { return (

My Global Header

{children}

) } ``` Now the structure becomes: ```text Header ↓ Current Page ↓ Footer ``` Every page wrapped by this root layout gets the same global structure. --- # What is `{children}`? You'll see this everywhere in layouts: ```jsx {children} ``` It might look mysterious at first. It's actually simple. `children` represents whatever Next.js needs to render **inside the layout**. Suppose you visit: ```text /about ``` and your: ```text about/page.jsx ``` contains: ```jsx export default function AboutPage() { return (

About Us

) } ``` Your layout contains: ```jsx

{children}

``` Conceptually, Next.js produces something like: ```jsx

``` So think of: ```jsx {children} ``` as: > "Put the current page here." Simple. --- # Nested Layouts Now layouts start getting really useful. You don't have to use only one global layout. You can create **nested layouts** for specific sections of your application. Imagine this structure: ```text src/app/ ├── layout.jsx ├── page.jsx │ └── dashboard/ ├── layout.jsx ├── page.jsx │ └── settings/ └── page.jsx ``` There are now two layouts: ```text Root Layout ``` and: ```text Dashboard Layout ``` The dashboard layout only applies to routes inside: ```text /dashboard ``` --- ## How Nested Layouts Stack Suppose the user visits: ```text /dashboard/settings ``` Next.js conceptually builds: ```text Root Layout ↓ Dashboard Layout ↓ Settings Page ``` Or in [JSX](/courses/reactjs)-ish form: ```jsx ``` This is one of the most important mental models for understanding the App Router. Layouts **nest inside each other**. --- # Real Example: Dashboard Layout A dashboard normally has UI such as: ```text Sidebar Dashboard Header Navigation Main Content ``` Instead of adding the sidebar to every dashboard page, create: ```text src/app/dashboard/layout.jsx ``` Example: ```jsx import Link from "next/link" export default function DashboardLayout({ children }) { return (

{children}

) } ``` Now: ```text /dashboard ``` and: ```text /dashboard/settings ``` both automatically get the sidebar. --- ## `/dashboard` When visiting: ```text /dashboard ``` the structure is: ```text Root Layout ↓ Dashboard Layout ↓ dashboard/page.jsx ``` --- ## `/dashboard/settings` When visiting: ```text /dashboard/settings ``` the structure becomes: ```text Root Layout ↓ Dashboard Layout ↓ dashboard/settings/page.jsx ``` The dashboard layout is still shared. Only the child route changes. --- # Partial Rendering This behavior has a name: **Partial Rendering** When navigating between routes that share layouts, Next.js can update the changing route segments while preserving the shared layout. For example: ```text /dashboard ``` to: ```text /dashboard/settings ``` doesn't mean: ```text Destroy everything ↓ Download everything again ↓ Rebuild entire page ``` Instead, the shared layout remains part of the navigation tree while the page content changes. Conceptually: ```text Before Root Layout └── Dashboard Layout └── Dashboard Page ``` Navigation happens: ```text /dashboard ↓ /dashboard/settings ``` Then: ```text After Root Layout └── Dashboard Layout └── Settings Page ``` The shared layouts are reused. --- ## Why Is This Useful? Imagine your dashboard has an interactive sidebar. The sidebar might contain: - Open/closed sections - Dropdowns - Search - Filters - Other client-side UI state If those interactive parts live in Client Components inside a persistent layout, their state can remain intact while navigating between child pages. This creates a smoother experience. You don't have to rebuild the whole application shell every time the URL changes. --- > **Interview Highlight** > > **Q: What happens when navigating from `/dashboard` to `/dashboard/settings`?** > > The shared root and dashboard layouts are reused through partial rendering while the changed child route is updated. This reduces unnecessary work and allows Client Component state inside persistent shared UI to remain preserved. --- # Another Nested Layout Example Suppose you're building an e-commerce website. You might have: ```text src/app/ ├── layout.jsx │ └── account/ ├── layout.jsx ├── page.jsx │ ├── orders/ │ └── page.jsx │ └── settings/ └── page.jsx ``` The root layout might contain: ```text Main Navbar Footer ``` while the account layout contains: ```text Account Sidebar Account Navigation ``` Visit: ```text /account/orders ``` and the user gets: ```text Root Layout │ ├── Main Navbar │ ├── Account Layout │ ├── Account Sidebar │ └── Orders Page │ └── Footer ``` This lets you build complex applications from small reusable layout layers. Pretty clean. 😎 --- # Root Layout vs Nested Layout Here's the difference. | Feature | Root Layout | Nested Layout | |---|---|---| | Location | `app/layout.jsx` | Any nested route folder | | Required | Yes | No | | Applies to | Entire application | Its route segment and descendants | | Defines `` and `` | Yes | No | | Common Use | Global shell | Section-specific shell | For example: ```text app/layout.jsx ``` might contain: ```text Global Navbar Footer ``` while: ```text app/dashboard/layout.jsx ``` contains: ```text Dashboard Sidebar Dashboard Header ``` Different responsibilities. Same layout system. --- # Layouts Can Be Server Components Remember an important App Router rule: > Components are [Server Components](/courses/nextjs) by default. That includes: ```text layout.jsx ``` So this: ```jsx export default function DashboardLayout({ children }) { return (

{children}

) } ``` is a Server Component by default. That's perfectly fine. --- # What If the Layout Needs Interactivity? Suppose your sidebar needs: ```js useState() ``` You don't necessarily need to turn the entire layout into a Client Component. Instead, create a smaller Client Component. For example: ```jsx // components/Sidebar.jsx "use client" import { useState } from "react" export default function Sidebar() { const [open, setOpen] = useState(true) return ( ) } ``` Then use it inside your layout: ```jsx import Sidebar from "@/components/Sidebar" export default function DashboardLayout({ children }) { return (

{children}

) } ``` Now you get: ```text Server Layout ↓ Interactive Client Sidebar ↓ Page ``` This is generally a better mental model than making huge parts of your application client-side unnecessarily. --- # Layouts vs Templates Next.js has another special file: ```text template.jsx ``` At first glance, it looks suspiciously similar to: ```text layout.jsx ``` And honestly... it kind of is. But there's one huge behavioral difference. Layouts **persist across matching navigations**. Templates **remount when their relevant route segment changes**. --- ## Layout Example ```jsx export default function Layout({ children }) { return (

{children}

) } ``` --- ## Template Example ```jsx export default function Template({ children }) { return (

{children}

) } ``` They look almost identical. So why have both? Because of what happens during navigation. --- # Layout Behavior Suppose an interactive component inside a persistent layout has: ```js const [search, setSearch] = useState("") ``` The user types: ```text nextjs routing ``` Then navigates between child pages that share that layout. Because the layout persists, that Client Component's state can remain: ```text nextjs routing ``` instead of resetting. --- # Template Behavior A template behaves differently. When its route segment changes, Next.js creates a new instance. That means Client Components inside it are remounted. Their state resets. Effects can run again. DOM elements inside that template are recreated. For example: ```js const [search, setSearch] = useState("") ``` User types: ```text nextjs routing ``` Navigation remounts the relevant template. State returns to: ```text "" ``` Fresh start. --- # Layout vs Template Here's the important comparison: | Feature | `layout.jsx` | `template.jsx` | |---|---|---| | Shared UI | Yes | Yes | | Persists across matching navigation | Yes | No, remounts when its segment changes | | Preserves child Client Component state | Yes | No | | Re-runs effects because of remount | Normally no | Yes | | Recreates DOM on remount | No | Yes | | Common Use | Navbar, sidebar, shared shell | Resetting state, re-running effects, some transition patterns | --- ## When Should You Use a Layout? Use: ```text layout.jsx ``` for UI you want to persist. Examples: - Navbar - Sidebar - Footer - Dashboard shell - Account navigation - Admin navigation - Shared providers - Section-level UI In most cases, **layout is what you want**. --- ## When Should You Use a Template? Use: ```text template.jsx ``` when you intentionally want a fresh instance during relevant navigation. Examples include: - Resetting form state - Resetting input state - Re-running `useEffect` - Re-triggering certain UI transitions - Showing Suspense fallback behavior again on navigation Templates are more specialized. If you're thinking: > "Do I need a template here?" and you don't have a specific reason... you probably want a layout. 😄 --- > **Interview Highlight** > > **Q: What is the main difference between `layout.jsx` and `template.jsx`?** > > A layout persists across matching navigations and can preserve Client Component state. A template receives a new instance when its relevant route segment changes, causing its child Client Components to remount and reset their state. --- # How Layout and Template Nest If a route has both: ```text layout.jsx ``` and: ```text template.jsx ``` the simplified structure looks like: ```text Layout ↓ Template ↓ Page ``` Conceptually: ```jsx ``` So the layout can remain persistent while the template inside it gets a fresh instance during the appropriate navigation. Pretty clever. --- # Metadata in Layouts Layouts are also useful places to define metadata. For example: ```jsx export const metadata = { title: "Dashboard" } ``` All routes inside that layout can inherit metadata behavior from it. But Next.js gives us an even nicer feature: **title templates**. --- # Metadata Title Templates Suppose every dashboard page should end with: ```text | Dashboard ``` You don't want to manually write: ```text Settings | Dashboard Users | Dashboard Analytics | Dashboard Billing | Dashboard ``` on every page. Instead, define a title template in the layout. ```jsx export const metadata = { title: { template: "%s | Dashboard", default: "Dashboard Overview", }, } ``` The: ```text %s ``` acts as a placeholder for the child page title. --- ## Child Page Metadata Now your settings page can simply define: ```jsx export const metadata = { title: "Settings", } ``` Next.js combines it with the parent template. The final browser title becomes: ```text Settings | Dashboard ``` Very clean. --- ## Another Example Root layout: ```jsx export const metadata = { title: { template: "%s | MyStore", default: "MyStore", }, } ``` Product page: ```jsx export const metadata = { title: "MacBook Pro", } ``` Final result: ```text MacBook Pro | MyStore ``` No repeating: ```text | MyStore ``` on every page. Your future self approves. ✅ --- # A Real-World Application Structure Let's imagine a fairly realistic SaaS application. ```text src/app/ ├── layout.jsx ├── page.jsx │ ├── pricing/ │ └── page.jsx │ ├── dashboard/ │ ├── layout.jsx │ ├── page.jsx │ │ │ ├── analytics/ │ │ └── page.jsx │ │ │ ├── customers/ │ │ └── page.jsx │ │ │ └── settings/ │ └── page.jsx │ └── account/ ├── layout.jsx ├── page.jsx │ └── security/ └── page.jsx ``` The hierarchy becomes: ```text Root Layout │ ├── Home │ ├── Pricing │ ├── Dashboard Layout │ ├── Dashboard │ ├── Analytics │ ├── Customers │ └── Settings │ └── Account Layout ├── Account └── Security ``` This is why layouts are such a powerful part of the App Router. You can build your application as layers of reusable UI instead of copying the same shell everywhere. --- # The Mental Model The easiest way to understand layouts is: ```text layout.jsx ↓ "Everything below me gets wrapped by this UI." ``` So: ```text app/layout.jsx ``` wraps essentially the whole application. While: ```text app/dashboard/layout.jsx ``` wraps the dashboard section. And: ```text app/dashboard/settings/layout.jsx ``` would wrap the settings section even deeper. Layouts keep stacking. --- ## Visual Example Suppose you have: ```text app/ ├── layout.jsx │ └── dashboard/ ├── layout.jsx │ └── settings/ ├── layout.jsx └── page.jsx ``` Visiting: ```text /dashboard/settings ``` creates a structure conceptually like: ```text Root Layout ↓ Dashboard Layout ↓ Settings Layout ↓ Settings Page ``` That's nested layouts in one picture. --- # Summary Layouts let you share UI across multiple routes without repeating the same components on every page. The important things to remember are: - `app/layout.jsx` is the root layout - The root layout defines `` and `` - `{children}` represents the nested page or layout - Nested folders can have their own `layout.jsx` - Layouts stack together - Shared layouts are reused during client-side navigation - This behavior is called partial rendering - Client Component state inside persistent layout UI can remain preserved - Layouts are [Server Components](/courses/nextjs) by default - Interactive pieces can be extracted into smaller Client Components - `template.jsx` looks similar to a layout but remounts during relevant navigation - Templates are useful when you intentionally want state or effects to reset - Layouts can define reusable metadata title templates The big idea is simple: ```text Pages = Content that changes Layouts = UI that stays around ``` Once you understand that, nested layouts become much easier. And that's the approach we'll keep using on **asif.to** — turning Next.js concepts that initially look like framework wizardry into simple mental models you can actually remember while building real projects. Less memorizing docs, more "ohhh, THAT'S why this exists." 🚀