The use client Directive

Your dashboard page renders a <RevenueChart> that calls useState, and the dev server stops with You're importing a component that needs "useState". This React Hook only works in a Client Component.... So you add 'use client' to the page. The error clears — and now every import that page pulls in ships to the browser as JavaScript. The directive solved the error while moving the boundary one level higher up the tree than you intended. Nothing about the page changed except which modules the bundler now treats as client code — the server-rendered default you learned in Server Components by Default still governs every module no directive has opted out.

The directive is a marker on the module graph, not a switch on the JSX tree. Next.js describes it as declaring "a boundary between the Server and Client module graphs." When a file begins with 'use client', the bundler treats that module plus every module it transitively imports as client code: those files are bundled for the browser, executed during hydration, and re-executed on every client-side render. Nothing below the directive in the JSX output matters, and nothing above it in JSX makes you safe.

Placement rules are strict and worth memorizing:

• It must be the first statement of the file, above the imports. Comments before it are allowed.
• It must use single or double quotes. Backticks are rejected.
• It only means something when server code imports the file. When another client module imports it, the directive changes nothing.

'use client';   // line 1, before imports

import { useState } from 'react';
import { formatMoney } from '@/lib/format';  // now part of the client graph
import { Button } from './Button';           // client too, directive not required

export function AddToCart({ sku, price }) {
  const [added, setAdded] = useState(false);
  // ...
}

Two subtleties separate a passing answer from a great one in interviews. First: 'use client' does not mean "runs only in the browser." Client components render on the server for the initial HTML pass too, which is why touching window during render still blows up during prerender with ReferenceError: window is not defined. The directive means the module is also downloaded and run in the browser, so browser-only APIs belong inside useEffect.

Second, because the boundary cuts the import tree rather than the render tree, one definition can execute in both environments. React's docs use a FancyText component defined without the directive: imported by a server page it is a Server Component usage and only its rendered output crosses the wire; imported and rendered inside a client InspirationGenerator, the same function becomes a Client Component usage and its source ships to the browser. Component usage, not component definition, decides which side you are on.

That same fact explains why a client component can render server components it never imports: you hand them over as JSX children. The server creates the JSX and renders it before the client component starts, so the client receives finished output rather than server source code. The full mechanics are in Crossing the Client Boundary.

Next.js fails loudly when server code needs a client runtime. Learning to read the three common messages by sight turns a debugging session into a ten-second fix.

Error 1 — a hook import. When a file in the server module graph calls a client-only hook, compilation stops with a message naming the hook:

You're importing a component that needs "useState".
This React Hook only works in a Client Component but none of its parents
are marked with "use client", so they're Server Components by default.

Wordings vary slightly across releases (Next.js 15 shortens it to This React Hook only works in a Client Component), but the shape is stable: hook name, then "Client Component." The fix is to add the directive to the component's own file, not to the page. Marking the page fixes the symptom and drags the whole page's import graph into the bundle — the mistake the previous chapter priced out.

Error 2 — an event handler crossing the boundary. If server code passes a function into anything React has to serialize for the client, you get:

Error: Event handlers cannot be passed to Client Component props.
  <button onClick={function} children=...>
         ^^^^^^^^^^^^^^^^^^^^^
If you need interactivity, consider converting part of this to a Client Component.

Read that carefully: the message blames "Client Component props," but the offender is almost always server-side code — a page.tsx without the directive rendering <button onClick={...}>, or a server page passing onClick={handler} into a client <Button>. React maintainers have fielded complaints about this wording (issue #61058); the rule underneath is simple: functions defined in server code cannot reach the client, with one exception — a Server Function marked 'use server'. The fixes are either moving the handler into a client component or passing data down and letting the client define its own callback.

Error 3 — metadata on a marked file. If you put 'use client' on a page or layout that also exports metadata, the build reports:

You are attempting to export "metadata" from a component marked with
"use client", which is disallowed. Either remove the export, or the
"use client" directive.

Metadata must be resolved on the server before the page renders, so the segment file has to stay server-side. Extract the interactive subtree into its own file with the directive and import it.

Equally important is what does not require the directive. Server Components can await, and they may use useId, useMemo, useCallback, and React's cache() — none of them depend on state, effects, or browser APIs. Also delete a common mix-up from your vocabulary: there is no directive for Server Components. 'use server' marks Server Functions (callable endpoints), not server components.

Third-party libraries are the last trap. A package that uses hooks without shipping its own directive compiles fine — Next.js skips its hook check inside node_modules — and then fails during prerender with a TypeError naming the hook. The documented fix is a two-line wrapper:

'use client';
export { Carousel } from 'acme-carousel';

Next.js also honors the server-only and client-only marker packages so importing a secret-holding module from client code fails with a clear message instead of leaking.

Timing matters when you triage these. Statically rendered routes surface them during next build's prerender step, so CI catches them before users do; dynamic routes throw on the first request instead. If an error only shows up in production, check whether the route is dynamic — the boundary rule is identical, only the moment you meet it moves. A quick audit after the fix: grep the client chunks in .next/static/chunks for a string that exists only in your server-only file. Finding it there means the directive, or something it imports transitively, is still pulling server code into the browser.

The performance question in an interview is rarely "what does 'use client' do" — it is "where do you put it, and how do you know you got it right?" The official guidance is one sentence: move Client Components to the leaves of your component tree where possible.

Consider a product page. The page itself needs to query the database, so it stays a Server Component. Only the add-to-cart button needs state and click handling:

// app/products/[sku]/page.tsx — Server Component, no directive
import db from '@/lib/db';
import AddToCartButton from './AddToCartButton';

export default async function ProductPage({ params }) {
  const product = await db.product.findUnique({ where: { sku: params.sku } });
  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <AddToCartButton sku={product.sku} price={product.price} />
    </main>
  );
}

// AddToCartButton.tsx — the leaf island
'use client';
import { useState } from 'react';

export default function AddToCartButton({ sku, price }) {
  const [quantity, setQuantity] = useState(1);
  // ...
}

Everything above the button — the database call, the markdown renderer, the review list — executes on the server and never enters the browser bundle. Move the directive up to page.tsx and all of it does.

The cost is measurable. Run next build with the directive on the leaf, note the route's size table (the First Load JS column), then move it to the page and build again. In a typical app the difference is not a few kilobytes: the page-level directive drags every route-local import into the client chunk, often doubling or tripling what the browser must download and parse before the page becomes interactive. The bundle number is your argument — quote it when an interviewer asks how you would justify keeping a component server-side.

The bytes are only half the tax. Once a segment file carries the directive you cannot await data in it — async components are not supported on the client — so fetching migrates into useEffect, which runs after hydration. The user now waits for the HTML, then the JS, then the request: latency you removed by keeping the page on the server.

Two honest counterweights show depth. First, there are cases where you force a component to be a client component on purpose: React's docs note that when a component's output HTML is much larger than its source — a component returning a very long inline SVG path, say — shipping the source can be cheaper than re-serializing its markup on every server render. Second, a client component at the root is sometimes structural rather than lazy: a theme or auth provider must call createContext, which has no server equivalent, so the provider file is client code while the server children it wraps are not.

Before adding the directive, run this quick audit:

When you are done, the shape you want is a mostly-server tree with a handful of small interactive islands — that is the design the directive exists to make possible, and the placement discipline that Crossing the Client Boundary builds on.