## What is the App Router? The **App Router** is the new routing system and application architecture introduced in Next.js 13+. It uses the `app/` directory for convention-based routing (where files define routes) and leverages **React Server Components (RSC)** as the default capability, fundamentally reimagining how we organize layouts, pages, loading states, error handling, and data fetching. If you think of the Pages Router as "page-centric" (using `pages/`), the App Router is more "route segment and layout tree-centric" (using `app/`): each route segment can have its own layout, loading state, and error boundary, which compose together to form a complete UI tree. ## Why Does It Matter? 1. **Enhanced layouts and navigation**: Supports nested layouts, persistent layouts, and partial refreshes, reducing redundant renders and requests. 2. **Server-first by default (less JS)**: Pages are Server Components by default, allowing more rendering and data fetching on the server, reducing client-side bundle size. 3. **Better loading and error boundaries**: Each route segment can independently define `loading.tsx` / `error.tsx`, improving user experience and maintainability. 4. **More natural full-stack capabilities**: Route Handlers (`app/api/**/route.ts`) and Server Actions make monorepo full-stack development more seamless. 5. **Foundation for future features**: Capabilities like parallel routes, intercepting routes, and Streaming/Suspense are more complete under the App Router. ## Core Concepts & How It Works ### Route Segments and Convention Files In the App Router, a URL is typically determined by the directory structure under `app/`: - `page.tsx`: The page entry point for this segment - `layout.tsx`: The shared layout for this segment and its children (can be nested) - `loading.tsx`: The loading UI for this segment (based on Suspense) - `error.tsx`: The error boundary for this segment (must be a Client Component) - `not-found.tsx`: The 404 page for this segment A minimal example: ```typescript // app/layout.tsx export default function RootLayout({ children }: { children: React.ReactNode }) { return ( {children} ); } ``` ```typescript // app/page.tsx export default function HomePage() { return

Home Page

; } ``` ### Server Components vs Client Components - **Server Components by default**: Components without `"use client"` render on the server and can directly access server resources (databases, private APIs, environment variables, etc.). - **Client Components for interactivity**: Use these for button clicks, instant form validation, `useState/useEffect`, etc. ```typescript // app/dashboard/page.tsx (Server Component, default) import { getServerSession } from "@/lib/auth"; // Example: server-side session access export default async function DashboardPage() { const session = await getServerSession(); return

Welcome, {session.user.name}

; } ``` ```typescript // app/dashboard/ClientButton.tsx (Client Component) "use client"; import { useState } from "react"; export function ClientButton() { const [count, setCount] = useState(0); return ; } ``` ### Nested Layouts and Shared UI App Router layouts compose in a tree structure. You can provide an independent layout for a specific segment while inheriting parent layouts: ```typescript // app/dashboard/layout.tsx export default function DashboardLayout({ children }: { children: React.ReactNode }) { return (

{children}

); } ``` ### Data Fetching and Caching (Intuitive Version) In the App Router, the common recommendation is: - **Fetch data directly in Server Components** (simpler approach) - External `fetch` requests are cached and deduplicated by default (can configure `cache` / `revalidate` as needed) - For "update UI after submission," commonly use **Server Actions** or combine with `revalidatePath/revalidateTag` (For deeper dives, see related entries on `nextjs-server-actions` and `nextjs-server-components`.) ## Real-World Examples ### Scenario 1: Building a Detail Page with Loading State and Error Boundary (Dynamic Route) ```typescript // app/posts/[slug]/page.tsx import { notFound } from "next/navigation"; async function getPost(slug: string) { // Example: fetch from your API/database const res = await fetch(`https://example.com/api/posts/${slug}`, { cache: "no-store" }); if (res.status === 404) return null; if (!res.ok) throw new Error("Failed to load"); return res.json(); } export default async function PostPage({ params }: { params: Promise<{ slug: string }> }) { const { slug } = await params; const post = await getPost(slug); if (!post) notFound(); return (

{post.title}

{post.content}

); } ``` ```typescript // app/posts/[slug]/loading.tsx export default function Loading() { return

Loading article...

; } ``` ```typescript // app/posts/[slug]/error.tsx "use client"; export default function Error({ reset }: { reset: () => void }) { return (

An error occurred while loading the article.

); } ``` **Explanation**: `page.tsx` executes on the server and fetches data; while the request is pending, `loading.tsx` is displayed; errors are caught by `error.tsx`; missing resources trigger `notFound()` to enter the segment's 404 logic. ### Scenario 2: Using Layout to Give an "Account Section" a Unified Shell and Authorization Check ```typescript // app/account/layout.tsx import { redirect } from "next/navigation"; import { getServerSession } from "@/lib/auth"; // Example export default async function AccountLayout({ children }: { children: React.ReactNode }) { const session = await getServerSession(); if (!session) redirect("/login"); return (

Account Center

{children}

); } ``` **Explanation**: By placing "authentication + unified shell" in `layout.tsx`, you ensure all pages under `app/account/**` are automatically protected, while reducing repetitive authorization checks in each page. ## Best Practices > **💡 Tip 1: Use Server Components by default, only drop down to Client Components when interactivity is needed.** This significantly reduces client-side JS and makes data access more intuitive. 1. **Place shared UI in the layout layer**: Navigation, sidebars, authorization checks, global providers, etc., should primarily live in `layout.tsx`. 2. **Add boundary files for critical route segments**: Adding `loading.tsx` / `error.tsx` / `not-found.tsx` to core pages will elevate user experience significantly. 3. **Make dynamic routes and data fetching predictable**: Be explicit about which pages need real-time data (`no-store`) and which can use incremental updates (`revalidate`). 4. **Let route structure express business logic**: For example, route groups like `app/(marketing)` or `app/(app)` (parenthesized directories) keep URLs clean while making structure clearer. > **⚠️ Common Pitfall: Using browser APIs or React hooks (useState/useEffect) directly in Server Components.** Components that need interactivity should have `"use client"` and maintain clear boundaries. ## Common Questions ### Do I have to choose between App Router and Pages Router? **Answer**: No, they can coexist. You can migrate gradually, putting new features in `app/` while keeping old pages in `pages/` until migration is complete. ### Why must my `error.tsx` be a Client Component? **Answer**: Because error boundaries rely on client-side error recovery mechanisms (like `reset()`), Next.js requires `error.tsx` to have `"use client"`. ### Does `layout.tsx` re-render on every navigation? **Answer**: Usually not. Layouts can persist (especially when navigating within the same layout tree), which is one of the key ways App Router improves experience and performance. ### When do I need Route Handlers (`app/api/**/route.ts`)? **Answer**: When you need to provide HTTP APIs (for third-party callbacks, webhooks, mobile apps, or external systems), Route Handlers are ideal; for form submissions alone, you might also consider Server Actions. ## Comparison with Other Concepts | Feature | App Router | Pages Router | | --- | --- | --- | | Routing directory | `app/` | `pages/` | | Default rendering mode | Server Components first | Client/server hybrid (page-centric) | | Layout capabilities | Nested layouts, stronger persistence | Requires manual wrapping and composition | | Loading/Error boundaries | Native support at route segment level | Requires custom implementation | | New feature support | Parallel/intercepting routes, Server Actions, etc. | Limited or requires additional solutions | ## Further Learning - [Next.js App Router Official Docs](https://nextjs.org/docs/app) - [Routing](https://nextjs.org/docs/app/building-your-application/routing) - [React Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) ## Related Terms - `nextjs-server-components` - `nextjs-server-actions` - `nextjs-middleware` - `nextjs-dynamic-routes` - `nextjs-parallel-routes` - `nextjs-metadata-api`