Frontend Beauty
ESC

Type to search the knowledge base.

Client Components in Next.js

Client Components in the App Router: use client, hydration, bundling boundaries, and patterns that keep JS small.

intermediate3 min read
  • nextjs
  • client-components

In the App Router, components are Server Components by default. Add "use client" at the top of a file to make it a Client Component entry — required for state, effects, and most browser APIs.

Docs: Client Components.

Declaring a client module

'use client';

import { useState } from 'react';

export function Counter() {
  const [n, setN] = useState(0);
  return (
    <button type="button" onClick={() => setN((x) => x + 1)}>
      {n}
    </button>
  );
}

The directive is per file, not per function. Everything imported into a client file becomes part of the client graph (with caveats for pure type imports).

SSR still happens

Client Components are still pre-rendered on the server by default and then hydrated. "use client" ≠ ssr: false. For browser-only widgets:

import dynamic from 'next/dynamic';
const Map = dynamic(() => import('./Map'), { ssr: false });

Use sparingly — you lose server HTML for that subtree.

Patterns

  1. Leaf interactivity — keep client modules small.
  2. Children slots — server content inside client chrome.
  3. Serializable props from server parents.
  4. Shared components — if a module needs hooks, it must be client; split presentational server pieces out.

Interview out-loud

“use client marks a Client Component boundary in the App Router. I push it to interactive leaves, pass serializable props from Server Components, and remember client components still SSR unless I opt out with dynamic ssr:false.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides