Week 16: Next.js — Server vs. Client Components

1. What Next.js Adds

Everything through Week 15 was a client-side rendered (CSR) app: Vite ships one near-empty HTML file, and the browser downloads and runs JavaScript that builds the entire page from scratch. That means a real, if brief, blank moment before anything appears, and search engines/link previews see very little without executing JavaScript first.

Next.js is a React framework that adds server-side rendering, file-based routing, and a build/deployment pipeline on top of React itself — it doesn't replace anything you've learned; hooks, components, props and state all work exactly the same. What changes is where code runs and how routing and data fetching are wired up.

npx create-next-app@latest my-app
cd my-app
npm run dev

2. Project Setup & File-Based Routing

The App Router (Next.js's current, recommended routing system) maps your file structure directly to URLs — no route configuration array like Week 6's createBrowserRouter. A folder is a URL segment; specific filenames inside it have special meaning.

app/
├── layout.tsx          # root layout -- wraps every page
├── page.tsx             # matches "/"
├── products/
│   ├── page.tsx          # matches "/products"
│   └── [productId]/
│       └── page.tsx      # matches "/products/:productId" -- dynamic segment
└── about/
    └── page.tsx          # matches "/about"

page.tsx defines the UI for that route; layout.tsx wraps every page beneath it — directly analogous to Week 6's <Outlet />-based nested layouts, except the nesting is expressed as folder nesting rather than a route config array. [productId] — square brackets around a folder name — is the App Router's equivalent of Week 6's :productId dynamic segment.

export default function ProductDetailPage({
  params,
}: {
  params: { productId: string };
}) {
  return <h1>Product #{params.productId}</h1>;
}

3. Server Components by Default

This is the biggest conceptual shift: in the App Router, every component is a Server Component by default. A Server Component renders entirely on the server — its code, and any large libraries it imports, never gets sent to the browser at all. The browser receives only the resulting HTML (and a lightweight description React uses to reconcile it) — not JavaScript for that component.

async function getProducts() {
  const res = await fetch('https://api.example.com/products');
  return res.json();
}

export default async function ProductsPage() {
  const products = await getProducts(); // runs on the SERVER, not in the browser

  return (
    <ul>
      {products.map((p: Product) => <li key={p.id}>{p.name}</li>)}
    </ul>
  );
}

Notice ProductsPage is an async function component — that's only valid for Server Components, and it means you can await data directly in the component body, no useEffect or useQuery needed for this kind of fetch. The generated HTML arrives already containing the product list; there's no client-side loading spinner for this data at all, because no client-side fetch ever happens.

4. The 'use client' Directive

A component needs to be a Client Component — hydrated and running in the browser, exactly like everything from Weeks 1–15 — the moment it needs interactivity: useState, event handlers, effects, browser-only APIs. Opt in with a 'use client' directive at the top of the file.

'use client'; // must be the very first line -- opts this whole module into the client bundle

import { useState } from 'react';

export function AddToCartButton({ productId }: { productId: number }) {
  const [added, setAdded] = useState(false);

  return (
    <button onClick={() => setAdded(true)}>
      {added ? 'Added ✓' : 'Add to cart'}
    </button>
  );
}

import { AddToCartButton } from '../AddToCartButton';

export default async function ProductDetailPage({ params }: { params: { productId: string } }) {
  const product = await getProduct(params.productId); // runs on the server

  return (
    <div>
      <h1>{product.name}</h1>               {/* rendered on the server, zero JS shipped for this part */}
      <AddToCartButton productId={product.id} /> {/* hydrated, interactive, runs in the browser */}
    </div>
  );
}

This is the pattern almost every real Next.js page follows: a Server Component handles data fetching and static content, and imports small, focused Client Components only for the specific pieces that need interactivity — the button, not the whole page. Everything outside those client islands ships zero JavaScript.

5. Choosing Server vs. Client

Default to a Server Component; add 'use client' only when you hit a genuine requirement for it:

• Stay a Server Component when: fetching data directly, reading environment secrets/API keys, rendering static or server-computed content, or including large dependencies you don't want shipped to the browser at all.
• Switch to a Client Component when: using useState/useEffect/any hook, attaching event handlers (onClick, onChange), using browser-only APIs (localStorage, window), or using a third-party library that itself depends on hooks or browser APIs.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.