Client Components

Opting In with "use client"

Adding the literal string "use client" as the very first line of a file marks every component in that file (and everything it exclusively imports into the client bundle) as a Client Component. Client Components render once on the server for the initial HTML (like any component), then hydrate in the browser, attaching event listeners and enabling hooks like useState and useEffect.

The directive applies at the module boundary: once a file is marked "use client", every component defined in that file is a Client Component, and Next.js includes it (and its dependencies) in the client-side JavaScript bundle.

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

Without "use client" at the top, this file would fail to build — useState and onClick are not allowed in Server Components.

Where the Directive Goes

"use client"; // must be the very first line, before any imports

import { useState } from "react";
// ... rest of the file

• The directive must be the literal first line of the file, before any imports.
• It applies to the whole file — you cannot mark just one function in a multi-component file as client-only.
• Once a component is a Client Component, everything it renders is also part of the client bundle by default (unless it receives Server Components as children).
• Client Components can still be rendered on the server for the initial HTML — "client" describes where they can run, not where they exclusively run.

Client Components Cheat Sheet

What requires opting in with "use client".

Pushing "use client" as Far Down as Possible

A common mistake is marking an entire page (or a large layout) as a Client Component just because one small button needs onClick. Instead, extract that button into its own tiny Client Component and keep everything else — including the surrounding page — as a Server Component.

// app/products/page.tsx (Server Component, no directive)
import AddToCartButton from "./AddToCartButton";

export default async function ProductsPage() {
  const products = await getProducts();
  return (
    <ul>
      {products.map((p) => (
        <li key={p.id}>
          {p.name} <AddToCartButton productId={p.id} />
        </li>
      ))}
    </ul>
  );
}

// app/products/AddToCartButton.tsx
"use client";
export default function AddToCartButton({ productId }: { productId: string }) {
  return <button onClick={() => addToCart(productId)}>Add to Cart</button>;
}

Only AddToCartButton.tsx ships as client JavaScript; the data fetching and list rendering stay entirely on the server.

Props Must Be Serializable

When a Server Component passes props to a Client Component, those props are serialized and sent across the server/client boundary, similar to JSON.stringify. This means functions, class instances, and other non-serializable values cannot be passed directly (with the notable exception of Server Actions, covered in a later lesson, which use a special mechanism).

Common Mistakes

• Marking a large layout or page as a Client Component to fix one small interactive element.
• Forgetting the directive must be the very first line, before any import statements.
• Trying to pass a non-serializable prop (like a database client instance) from a Server to a Client Component.
• Assuming a Client Component never runs on the server — it still renders server-side for the initial HTML.

Key Takeaways

• "use client" at the top of a file opts every component in it into being a Client Component.
• Client Components enable hooks, event handlers, and browser APIs.
• Push "use client" down to the smallest component that actually needs interactivity.
• Props from Server to Client Components must be serializable.
• Client Components still render on the server initially; the directive controls capability, not execution location exclusively.