Frontend Beauty
ESC

Type to search the knowledge base.

Client Component Boundaries

Where to put use client: push interactivity to leaves, serializable props, and children as server slots.

advanced3 min read
  • react
  • client-component

In React Server Components architectures (Next.js App Router), files are Server Components by default. "use client" marks a module as a Client Component entry — it and its imports ship to the browser for interactivity.

Docs: Server Components, Next Client Components.

Push the boundary down

// page.tsx — Server Component
import { LikeButton } from './like-button'; // client
import { db } from '@/lib/db';

export default async function PostPage({ params }) {
  const post = await db.posts.get((await params).id);
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
      <LikeButton postId={post.id} initial={post.likes} />
    </article>
  );
}
// like-button.tsx
'use client';
import { useState } from 'react';

export function LikeButton({ postId, initial }) {
  const [likes, setLikes] = useState(initial);
  return (
    <button type="button" onClick={() => setLikes((n) => n + 1)}>
      {likes}
    </button>
  );
}

Do not slap "use client" on the entire page if only a button needs state.

Composition pattern

Client components cannot import server components. They can receive server-rendered content as children:

'use client';
export function Tabs({ children }) {
  const [i, setI] = useState(0);
  return <div>{/* switch visibility */}{children}</div>;
}

Server parent passes server children into the client shell — see Next server components.

Serializable props only

Pass JSON-friendly data (and supported rich types per docs). Not functions (except Server Actions), class instances, or complex cycles.

Interview out-loud

“Client boundaries start at use client modules. I keep them as low as possible, pass serializable props, and use children slots so server content can render inside client chrome without importing server modules into the client bundle.”

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