Server vs client components

Server Components are the default — they run on the server, ship zero JS, and can await data directly. There is no directive to opt in; a plain component in the App Router is a Server Component. It runs during the request, can be async, and can read your data layer inline. Its rendered output is serialized to the client; its source code never is.

// app/users/page.tsx — no directive = Server Component
import { db } from "~/lib/db";

export default async function UsersPage() {
  const users = await db.user.findMany(); // runs on the server, secrets stay server-side
  return (
    <ul>
      {users.map((u) => <li key={u.id}>{u.name}</li>)}
    </ul>
  );
}

What it cannot do: hold state, run effects, attach event handlers, or touch browser APIs (window, localStorage). There is no client runtime for it — it already ran.

Client Components opt in with 'use client' — that’s where state, effects, events, and browser APIs live. The directive at the top of a file marks it (and everything it imports that isn’t already a Server Component) as code that ships to the browser and hydrates there. You reach for it only when a component genuinely needs interactivity.

// app/users/SearchBox.tsx
"use client";
import { useState } from "react";

export function SearchBox({ onChange }: { onChange: (q: string) => void }) {
  const [q, setQ] = useState("");           // state — needs the client
  return (
    <input
      value={q}
      onChange={(e) => { setQ(e.target.value); onChange(e.target.value); }} // event handler — needs the client
    />
  );
}

What it cannot do: await your database in the body or import server-only secrets. A Client Component runs in the browser, so it must fetch through an API or receive data as props from a Server Component above it.

The boundary is directional and viral: 'use client' marks an entry point, and everything imported below it becomes client code too. 'use client' is not “this one component is interactive” — it’s “the client bundle starts here”. Every module this file imports (that isn’t itself a Server Component boundary) is pulled into the browser bundle. That is why placement is the whole game: the directive’s position decides how much of your tree ships as JavaScript.

// WRONG instinct: mark the page so a child can use state
"use client";              // ⛔ now the page AND all its children are client code
import { Chart } from "./Chart";        // heavy — now in the bundle
import { Table } from "./Table";        // static — needlessly in the bundle
export default function Dashboard() { /* ...one button needed state... */ }

One component needed a click handler, so the entire dashboard — chart library, static table, all of it — became a client bundle and lost server data access. The fix is never to move the boundary up; it’s to push it down.

Default to Server Components and push 'use client' down to the interactive leaves. Keep parents on the server, hand interactive bits to small client leaves, and pass server-rendered content into them as children or props. A Client Component can render Server Components passed as children — they were already rendered on the server — so the client boundary stays a thin shell around the truly interactive part.

// Server Component parent — data + composition stay on the server
export default async function Dashboard() {
  const data = await getMetrics();
  return (
    <section>
      <Chart data={data} />                {/* Server Component: zero JS */}
      <Collapsible>                        {/* tiny Client leaf for the toggle */}
        <Table rows={data.rows} />         {/* Server Component, passed as children */}
      </Collapsible>
    </section>
  );
}

// Collapsible.tsx — the ONLY client code here
"use client";
import { useState } from "react";
export function Collapsible({ children }: { children: React.ReactNode }) {
  const [open, setOpen] = useState(false);
  return (
    <>
      <button onClick={() => setOpen((o) => !o)}>{open ? "Hide" : "Show"}</button>
      {open && children}                   {/* server-rendered Table, no extra JS */}
    </>
  );
}

Now only Collapsible ships JS. The chart, the table, and the data fetch stay on the server. The boundary is a leaf, not a root.