## How File-Based Routing Works Routing sounds like one of those scary framework words. But in [Next.js](/courses/nextjs), the basic idea is surprisingly simple: > **Your folder structure becomes your URL structure.** That's it. If you're coming from [React Router](/courses/reactjs), you may be used to creating routes manually: ```jsx } /> } /> ``` Perfectly valid. But [Next.js](/courses/nextjs) looks at that and says: > "Why are we writing the URLs twice?" 😭 With the [App Router](/courses/nextjs), you create folders inside: ```text src/app/ ``` and Next.js automatically turns them into routes. For example: ```text src/app/ ├── page.jsx ├── about/ │ └── page.jsx └── dashboard/ └── page.jsx ``` creates: ```text / /about /dashboard ``` No separate router configuration. No giant list of routes. Your project structure basically becomes the map of your website. > **Definition: File-Based Routing** > > File-based routing is a routing system where folders and special files inside the `app/` directory determine the URLs and behavior of your application. --- ## Basic Routes — When You Already Know the URL Let's start with the easiest case. Suppose your website needs: ```text Home About Dashboard Dashboard Settings ``` And you already know the URLs: ```text / /about /dashboard /dashboard/settings ``` These are fixed routes. Nothing dynamic. Nothing fancy. Just folders. --- ## Creating Basic Routes Create this structure: ```text src/app/ ├── page.jsx ├── about/ │ └── page.jsx └── dashboard/ ├── page.jsx └── settings/ └── page.jsx ``` Next.js automatically maps them like this: ```text src/app/page.jsx ↓ / src/app/about/page.jsx ↓ /about src/app/dashboard/page.jsx ↓ /dashboard src/app/dashboard/settings/page.jsx ↓ /dashboard/settings ``` Very important rule: > **A route segment becomes an accessible UI page when it contains a `page.jsx` file.** For example: ```text src/app/ └── dashboard/ ├── components/ │ └── Sidebar.jsx └── page.jsx ``` You can visit: ```text /dashboard ``` But this: ```text dashboard/components/ ``` doesn't automatically create: ```text /dashboard/components ``` because there's no: ```text components/page.jsx ``` So don't worry. You can safely create folders for: - Components - Helpers - Utilities - Data - [Hooks](/courses/reactjs/chapter-11-advanced-hooks-useref-usereducer-usememo-usecallback) inside your route structure without accidentally turning every folder into a webpage. --- ## When Should You Use Basic Routes? Use regular folders when the URL is fixed and predictable. Examples: ```text /about /contact /pricing /login /register /dashboard /settings ``` If you already know the exact URL while writing the code, a basic route is usually enough. --- ## Nested Routes — Routes Inside Routes Now imagine you're building a dashboard. It contains: ```text /dashboard /dashboard/profile /dashboard/settings /dashboard/billing ``` All these pages logically belong to the: ```text /dashboard ``` section. Next.js lets your folder structure reflect that relationship. --- ## Creating Nested Routes You simply nest folders. ```text src/app/ └── dashboard/ ├── page.jsx │ ├── profile/ │ └── page.jsx │ ├── settings/ │ └── page.jsx │ └── billing/ └── page.jsx ``` This gives you: ```text /dashboard /dashboard/profile /dashboard/settings /dashboard/billing ``` Every nested folder adds another segment to the URL. Think of it like: ```text dashboard ↓ settings ↓ /dashboard/settings ``` Pretty much what you'd expect. And when framework behavior matches common sense, that's always a good day. 😌 --- ## When Should You Use Nested Routes? Use nested routes when pages logically belong inside another section. Examples: ```text /dashboard/settings /dashboard/users /account/security /products/laptops /courses/javascript /admin/products ``` One nice benefit is that your project becomes easier to understand. If you see: ```text app/dashboard/settings/ ``` you already know where it lives on the website. No detective work required. --- ## Dynamic Routes — `[param]` Now things get more interesting. Suppose you're building a blog with thousands of articles. Your URLs might look like: ```text /blog/nextjs-routing /blog/react-hooks /blog/javascript-promises /blog/nodejs-event-loop ``` You definitely don't want to create this manually: ```text blog/ ├── nextjs-routing/ │ └── page.jsx ├── react-hooks/ │ └── page.jsx ├── javascript-promises/ │ └── page.jsx └── nodejs-event-loop/ └── page.jsx ``` Imagine doing that for 10,000 articles. No thanks. 💀 Instead, you create **one dynamic route**. --- ## Creating a Dynamic Route Wrap the folder name in square brackets: ```text [slug] ``` Example: ```text src/app/ └── blog/ ├── page.jsx └── [slug]/ └── page.jsx ``` Now the same `page.jsx` can handle: ```text /blog/nextjs-routing /blog/react-hooks /blog/javascript-promises /blog/whatever-you-want ``` The value after: ```text /blog/ ``` becomes the dynamic: ```text slug ``` parameter. --- ## Accessing Dynamic Route Parameters Suppose the user visits: ```text /blog/nextjs-routing ``` You can access: ```text nextjs-routing ``` through the page's `params`. ```jsx export default async function BlogPost({ params }) { const { slug } = await params return (

Post: {slug}

) } ``` For: ```text /blog/nextjs-routing ``` the value becomes: ```js slug === "nextjs-routing" ``` For: ```text /blog/react-hooks ``` it becomes: ```js slug === "react-hooks" ``` --- ## What Do We Actually Do With the Slug? Usually, you'll use it to fetch data. For example: ```jsx export default async function BlogPost({ params }) { const { slug } = await params const post = await getPostBySlug(slug) return (

{post.title}

) } ``` Now one page template can display thousands of articles. Conceptually: ```text /blog/nextjs-routing ↓ slug = "nextjs-routing" ↓ Find article in database ↓ Render article ``` Then: ```text /blog/react-hooks ↓ slug = "react-hooks" ↓ Find another article ↓ Render it using the SAME page ``` That's the superpower of dynamic routes. --- ## When Should You Use Dynamic Routes? Use them when many pages have the same structure but different data. Examples: ```text /blog/[slug] /articles/[slug] /products/[id] /users/[username] /courses/[course] /orders/[orderId] ``` For example: ```text /products/92731 ``` might be handled by: ```text products/[id]/page.jsx ``` where: ```js id === "92731" ``` One route. Potentially millions of pages. Very efficient. --- ## Multiple Dynamic Segments You're not limited to one dynamic value. Imagine a learning platform with URLs like: ```text /courses/javascript/promises /courses/javascript/closures /courses/react/use-state /courses/nextjs/routing ``` Two things can change: ```text course chapter ``` So we can make both dynamic. ```text src/app/ └── courses/ └── [course]/ └── [chapter]/ └── page.jsx ``` Now: ```text /courses/javascript/promises ``` gives you: ```js { course: "javascript", chapter: "promises" } ``` You can access both: ```jsx export default async function ChapterPage({ params }) { const { course, chapter } = await params return ( <>

{course}

{chapter}

) } ``` This is extremely useful for: - Learning platforms - Documentation - E-commerce - Blogs - Knowledge bases - Category systems Instead of hardcoding every possible URL, your data decides which pages exist. --- ## Catch-All Routes — `[...slug]` Normal dynamic routes capture exactly one URL segment. For example: ```text /blog/[slug] ``` handles: ```text /blog/react ``` But what if you don't know how deep the URL will go? Imagine documentation like: ```text /docs/react /docs/react/hooks /docs/react/hooks/use-state /docs/javascript/promises/async-await ``` The number of segments keeps changing. You could create several nested dynamic folders... or you could save yourself the headache and use a **Catch-All Route**. --- ## Creating a Catch-All Route Use three dots: ```text [...slug] ``` Example: ```text src/app/ └── docs/ └── [...slug]/ └── page.jsx ``` Now: ```text /docs/react ``` can produce: ```js slug = ["react"] ``` While: ```text /docs/react/hooks ``` can produce: ```js slug = ["react", "hooks"] ``` And: ```text /docs/react/hooks/use-state ``` can produce: ```js slug = [ "react", "hooks", "use-state" ] ``` Notice the difference? A normal dynamic route gives you a string-like segment: ```js slug = "react" ``` A catch-all route gives you an array of segments: ```js slug = [ "react", "hooks", "use-state" ] ``` --- ## Accessing a Catch-All Parameter ```jsx export default async function DocsPage({ params }) { const { slug } = await params return (

{slug.join(" → ")}

) } ``` Visiting: ```text /docs/react/hooks/use-state ``` could display: ```text react → hooks → use-state ``` --- ## When Should You Use Catch-All Routes? Use `[...slug]` when the number of URL segments can vary. Good examples: ```text /docs/[...slug] /categories/[...slug] /files/[...path] /knowledge-base/[...slug] ``` One important detail: ```text /docs/[...slug] ``` matches: ```text /docs/react /docs/react/hooks /docs/react/hooks/use-state ``` but it does **not** match: ```text /docs ``` Why? Because a normal catch-all route requires at least one segment. That's where the next routing type comes in. --- ## Optional Catch-All Routes — `[[...slug]]` Suppose you want one route to handle all of these: ```text /docs /docs/react /docs/react/hooks /docs/react/hooks/use-state ``` The regular: ```text [...slug] ``` can't handle: ```text /docs ``` So we add another pair of square brackets. Yes, Next.js looked at `[...slug]` and said: > "Needs more brackets." 😭 The syntax becomes: ```text [[...slug]] ``` --- ## Creating an Optional Catch-All Route ```text src/app/ └── docs/ └── [[...slug]]/ └── page.jsx ``` Now one route can handle: ```text /docs /docs/react /docs/react/hooks /docs/react/hooks/use-state ``` For the parent route: ```text /docs ``` the optional parameter may be absent. So you should handle that possibility in your code. --- ## Catch-All vs Optional Catch-All This is a common interview question. > **Interview Highlight** > > **Q: What is the difference between `[...slug]` and `[[...slug]]`?** > > `[...slug]` requires at least one URL segment after the parent route. > > `[[...slug]]` also allows the parent route itself. Example: ```text [...slug] ``` matches: ```text /docs/react /docs/react/hooks ``` but not: ```text /docs ``` While: ```text [[...slug]] ``` matches: ```text /docs /docs/react /docs/react/hooks ``` Tiny syntax difference. Big routing difference. --- ## Route Groups — `(groupName)` Now imagine your application has different sections. You have public marketing pages: ```text / /about /pricing /contact ``` You also have authenticated pages: ```text /dashboard /settings /profile ``` You want your source code organized like: ```text marketing/ app/ ``` But you definitely don't want your URLs becoming: ```text /marketing/about /app/dashboard ``` because users don't care how your folders are organized. This is exactly what **Route Groups** solve. --- ## Creating Route Groups Wrap the folder name in parentheses: ```text (marketing) ``` Example: ```text src/app/ ├── (marketing)/ │ ├── layout.jsx │ ├── about/ │ │ └── page.jsx │ └── contact/ │ └── page.jsx │ └── (app)/ ├── layout.jsx └── dashboard/ └── page.jsx ``` Here's the cool part. This: ```text (marketing)/about/page.jsx ``` becomes: ```text /about ``` NOT: ```text /marketing/about ``` And: ```text (app)/dashboard/page.jsx ``` becomes: ```text /dashboard ``` NOT: ```text /app/dashboard ``` Parentheses basically tell Next.js: > "This folder is for us developers. Don't put it in the URL." --- ## Why Are Route Groups Useful? Route Groups help organize large applications. For example: ```text (marketing) (auth) (app) (admin) ``` You might organize your application like: ```text (auth)/ ├── login/ └── register/ (admin)/ ├── dashboard/ └── users/ (marketing)/ ├── about/ └── pricing/ ``` while users still see clean URLs: ```text /login /register /dashboard /users /about /pricing ``` Much cleaner. --- ## Route Groups and Layouts One of the biggest reasons to use Route Groups is **different layouts**. For example: ```text (marketing)/ └── layout.jsx ``` might contain: ```text Navbar Page Footer ``` while: ```text (admin)/ └── layout.jsx ``` might contain: ```text Sidebar Admin Header Page ``` Same application. Different sections. Different UI structures. Clean URLs. Very nice. > We'll explore **Layouts and Nested Layouts** properly in the next chapter. --- # Special Files in the App Router Routing in Next.js isn't only about: ```text page.jsx ``` The App Router includes several **special files**. Their filenames tell Next.js how a particular route should behave. | File | Purpose | |---|---| | `page.jsx` | Creates a UI page for a route | | `layout.jsx` | Shares UI between routes | | `template.jsx` | Similar to a layout but creates a new instance during navigation | | `loading.jsx` | Shows loading UI while route content loads | | `error.jsx` | Handles errors inside a route segment | | `not-found.jsx` | Shows UI when requested content isn't found | | `route.js` | Creates an HTTP endpoint instead of a page | You'll learn several of these in dedicated chapters. For now, let's understand what problems they solve. --- ## `loading.jsx` — When Your Page Needs Time Imagine you're loading analytics for a dashboard. Maybe the server needs to: ```text Fetch user ↓ Query database ↓ Calculate analytics ↓ Return page ``` That might take a moment. Without feedback, users may wonder: > "Did I click it?" > "Is the site broken?" > "Should I click it another 47 times?" Please don't. 😭 Instead, create: ```text dashboard/ ├── loading.jsx └── page.jsx ``` Example: ```jsx export default function Loading() { return (

Loading dashboard...

) } ``` Next.js can show this fallback UI while the route content is loading. You can make it much prettier with skeleton components: ```jsx export default function Loading() { return (

) } ``` Common uses include: - Skeleton screens - Dashboard loading states - Slow database queries - Data-heavy pages - Streaming interfaces Behind the scenes, `loading.jsx` works with [React](/courses/reactjs) Suspense and Next.js streaming. We'll explore that later. --- ## `error.jsx` — When Something Explodes APIs fail. Databases disconnect. Unexpected bugs happen. Production has a special talent for finding code paths you were absolutely sure nobody would ever reach. 💀 Instead of destroying the entire user experience, Next.js lets you create route-level error UI. Example: ```text dashboard/ ├── error.jsx └── page.jsx ``` Then: ```jsx "use client" export default function Error({ error, reset }) { return (

Something went wrong.

) } ``` Notice: ```jsx "use client" ``` at the top. That's required because error boundaries use client-side [React](/courses/reactjs) behavior. The: ```js reset() ``` [function](/javascript/functions-in-javascript) lets you attempt to render the failed route again. So instead of: ```text Error ↓ Entire experience dies ``` you can provide: ```text Error ↓ Friendly message ↓ Try Again ``` Much better UX. --- ## `not-found.jsx` — When Content Doesn't Exist Dynamic routes create another interesting problem. Suppose someone visits: ```text /blog/article-that-does-not-exist ``` Your: ```text blog/[slug] ``` route technically matches it. But your database says: ```text Article? Never heard of it. ``` You need to show a 404. Next.js provides: ```js notFound() ``` from: ```js next/navigation ``` Example: ```jsx import { notFound } from "next/navigation" export default async function BlogPost({ params }) { const { slug } = await params const post = await getPostBySlug(slug) if (!post) { notFound() } return (

{post.title}

) } ``` Then create: ```text blog/ ├── not-found.jsx └── [slug]/ └── page.jsx ``` Example: ```jsx export default function NotFound() { return (

404

We couldn't find that article.

) } ``` Now users get a useful page instead of something looking completely broken. --- ## Why `not-found.jsx` Is Useful It works especially well with dynamic content. Examples: ```text /products/[id] /blog/[slug] /users/[username] /courses/[course] ``` The URL structure may be valid while the actual data doesn't exist. That's exactly when: ```js notFound() ``` becomes useful. --- # `route.js` — When You Need an API Until now, our routes have returned UI. But not every URL should return [HTML](/courses/html). Sometimes you want: ```text GET /api/users POST /api/contact DELETE /api/products/123 ``` For that, Next.js provides **Route Handlers**. Instead of: ```text page.jsx ``` you create: ```text route.js ``` --- ## Creating a Route Handler Example: ```text src/app/ └── api/ └── users/ └── route.js ``` Then: ```js export async function GET() { return Response.json({ users: [] }) } ``` Now a request to: ```text GET /api/users ``` runs that [function](/javascript/functions-in-javascript). Pretty cool. Your frontend framework just quietly became your backend too. 😎 --- ## Supported HTTP Methods Route Handlers can respond to methods such as: ```text GET POST PUT PATCH DELETE HEAD OPTIONS ``` For example: ```js export async function GET() { return Response.json({ message: "Getting users" }) } export async function POST(request) { const body = await request.json() return Response.json({ message: "User created", data: body }) } ``` --- ## When Should You Use `route.js`? Route Handlers are useful for: - API endpoints - Form submissions - Webhooks - Authentication callbacks - Database operations - Third-party integrations - Public APIs - Backend services We'll explore Route Handlers properly in their own chapter. For now, just remember: ```text page.jsx ↓ UI Route ``` while: ```text route.js ↓ HTTP Endpoint ``` --- # Navigation in Next.js Creating pages is only half the story. Users need a way to move between them. Next.js gives us two major approaches: ```text ``` and: ```text useRouter() ``` Let's understand when to use each. --- ## The `` Component Suppose you want navigation from: ```text / ``` to: ```text /about ``` Normal [HTML](/courses/html) can do this: ```html About ``` But for internal Next.js navigation, you normally use: ```jsx ``` from: ```js next/link ``` Example: ```jsx import Link from "next/link" export default function Navigation() { return ( ) } ``` --- ## Why Use ``? `Link` integrates with the Next.js router. Instead of treating every internal navigation like loading a completely separate website, Next.js can perform optimized client-side transitions. It can also prefetch eligible routes so navigation feels faster. Conceptually: ```text User sees link ↓ Next.js may prepare destination ↓ User clicks ↓ Fast navigation ``` This is one of the reasons navigating through a Next.js application can feel very smooth. > **Interview Highlight** > > **Q: Why should we use `` instead of `` for internal Next.js navigation?** > > `` integrates with the Next.js router and provides optimized client-side navigation and route prefetching behavior. --- ## Internal vs External Links For routes inside your application: ```jsx About ``` For external websites, a regular anchor is perfectly appropriate: ```jsx GitHub ``` Simple rule: ```text Internal navigation ↓ ``` ```text External website ↓ ``` --- # Programmatic Navigation — `useRouter()` Sometimes users don't click a link. Imagine a login form. After login succeeds, you want to send the user to: ```text /dashboard ``` The navigation happens because your [JavaScript](/courses/javascript) logic decided it should happen. That's called **programmatic navigation**. --- ## Using `useRouter()` In the App Router, import it from: ```js next/navigation ``` Example: ```jsx "use client" import { useRouter } from "next/navigation" export default function LoginButton() { const router = useRouter() async function handleLogin() { // Perform login... router.push("/dashboard") } return ( ) } ``` Notice again: ```jsx "use client" ``` Why? Because: ```js useRouter() ``` is a Client Component hook. --- ## `router.push()` The most common navigation method is: ```js router.push("/dashboard") ``` It navigates to another route and adds the destination to the browser's history. For example: ```js router.push("/profile") ``` navigates to: ```text /profile ``` --- ## Other Useful Router Methods You'll also encounter methods such as: ```js router.replace("/dashboard") ``` which navigates without adding another history entry in the same way as `push`. And: ```js router.back() ``` which moves back in browser history. For example: ```jsx "use client" import { useRouter } from "next/navigation" export default function BackButton() { const router = useRouter() return ( ) } ``` --- ## When Should You Use `useRouter()`? Use programmatic navigation when navigation depends on logic. Examples: - After successful login - After registration - After submitting a form - After creating a post - After completing checkout - Based on a user's action - After deleting an item Example: ```js if (loginSuccessful) { router.push("/dashboard") } ``` For normal clickable navigation: ```jsx Dashboard ``` is usually preferable. --- # Which Routing Type Should You Use? You've now seen a lot of square brackets, parentheses, dots, and special filenames. So here's the cheat sheet. | Scenario | Use | |---|---| | Fixed page like `/about` | Basic route | | Page inside another section | Nested route | | Dynamic ID, username, or slug | `[param]` | | Unknown number of URL segments | `[...slug]` | | Parent route + optional nested segments | `[[...slug]]` | | Organize routes without changing URLs | `(group)` | | Shared UI between routes | `layout.jsx` | | Loading fallback | `loading.jsx` | | Route-level error handling | `error.jsx` | | Missing content | `not-found.jsx` | | HTTP/API endpoint | `route.js` | | Clickable internal navigation | `` | | Navigation triggered by logic | `useRouter()` | A useful mindset is: > **Don't ask, "Which Next.js routing feature should I use?"** Instead ask: > **"What kind of URL am I trying to create?"** Then choose the routing feature that solves that problem. --- # Real-World Example Let's put everything together. Imagine you're building an online learning platform. You need these routes: ```text / /about /courses /courses/javascript/promises /courses/react/hooks /dashboard /dashboard/profile /api/progress ``` A sensible project structure might look like: ```text src/app/ ├── page.jsx │ ├── (marketing)/ │ └── about/ │ └── page.jsx │ ├── courses/ │ ├── page.jsx │ │ │ └── [course]/ │ └── [chapter]/ │ └── page.jsx │ ├── (app)/ │ └── dashboard/ │ ├── layout.jsx │ ├── page.jsx │ │ │ └── profile/ │ └── page.jsx │ └── api/ └── progress/ └── route.js ``` Let's see why each part exists. --- ## Home Page ```text src/app/page.jsx ``` becomes: ```text / ``` Simple fixed route. --- ## Marketing Page ```text (marketing)/about/page.jsx ``` becomes: ```text /about ``` The route group organizes marketing pages without adding: ```text /marketing ``` to the URL. --- ## Courses ```text courses/page.jsx ``` becomes: ```text /courses ``` Then: ```text courses/[course]/[chapter]/page.jsx ``` can handle: ```text /courses/javascript/promises /courses/javascript/closures /courses/react/hooks /courses/nextjs/routing ``` Because both: ```text course ``` and: ```text chapter ``` come from data. --- ## Dashboard ```text (app)/dashboard/page.jsx ``` becomes: ```text /dashboard ``` Then: ```text (app)/dashboard/profile/page.jsx ``` becomes: ```text /dashboard/profile ``` The: ```text dashboard/layout.jsx ``` can share dashboard UI such as: ```text Sidebar Navbar User Menu ``` between dashboard pages. --- ## Progress API Finally: ```text api/progress/route.js ``` becomes an endpoint such as: ```text GET /api/progress ``` or: ```text POST /api/progress ``` depending on the handlers you create. --- # The App Router Mental Model The biggest thing to understand from this chapter is that URLs and folders are closely connected. Think: ```text Folder ↓ URL Segment ``` For example: ```text app/dashboard/settings/page.jsx ``` becomes: ```text /dashboard/settings ``` Dynamic folders add values: ```text app/products/[id]/page.jsx ``` handles: ```text /products/123 /products/456 /products/789 ``` Catch-all routes handle varying depth: ```text app/docs/[...slug]/page.jsx ``` handles: ```text /docs/react /docs/react/hooks /docs/react/hooks/use-state ``` Route Groups organize your code: ```text (marketing) (admin) (auth) ``` without changing the URL. And special files modify route behavior: ```text page.jsx layout.jsx loading.jsx error.jsx not-found.jsx route.js ``` Once this mental model clicks, Next.js routing stops looking like mysterious bracket soup. 😄 --- ## Summary Next.js App Router uses your file system to define routes. The main concepts are: - `page.jsx` creates a page - Nested folders create nested URLs - `[slug]` creates dynamic routes - Multiple dynamic folders capture multiple parameters - `[...slug]` creates catch-all routes - `[[...slug]]` creates optional catch-all routes - `(group)` organizes routes without changing URLs - `loading.jsx` provides loading UI - `error.jsx` handles route-level errors - `not-found.jsx` handles missing content - `route.js` creates HTTP endpoints - `` handles normal internal navigation - `useRouter()` handles programmatic navigation The most important rule isn't memorizing every bracket. It's understanding the URL problem first. Ask: ```text Is this page fixed? Is part of the URL dynamic? Can the URL have multiple unknown segments? Do I only need a folder for organization? Am I building a page or an API? ``` Once you answer that, Next.js usually gives you a routing pattern that fits naturally. And that's how we'll keep learning Next.js on **asif.to** — not by memorizing random framework syntax, but by understanding the problem each feature solves. Once the *why* makes sense, all those `[brackets]`, `(parentheses)`, and `...dots` suddenly stop looking like keyboard accidents. 🚀