React Server Components explained for teams shipping real products

What is a React Server Component?

A React Server Component is a component that runs only during rendering on the server and never ships its source code to the browser.

Rather than sending your component code plus data to the browser and rendering there, the server executes the component and streams a compact description of the resulting UI tree — the RSC payload — to React on the client. React uses that description to build the DOM and to reconcile with any client components in the tree.

The practical consequence: a server component can import a 300 KB markdown parser, a date library and your database client, and the browser downloads none of it. That is the entire point.

How does the "use client" boundary actually work?

"use client" at the top of a file marks an entry point into the client bundle. Every module that file imports — and everything those modules import — is compiled for the browser too. This is the single most misunderstood detail of the model.

The failure mode we see most often: a team puts "use client" in the root layout to make a theme provider work, and the entire application silently becomes a client application again. The App Router is still used, the performance benefit is gone.

// Wrong: the whole tree becomes client code
"use client";
export default function Layout({ children }) {
  return <ThemeProvider>{children}</ThemeProvider>;
}

// Right: only the provider is a client component
import { ThemeProvider } from "./theme-provider"; // "use client" lives there
export default function Layout({ children }) {
  return <ThemeProvider>{children}</ThemeProvider>;
}

Where should the boundary go?

The rule we apply on every project: the client boundary belongs at the smallest interactive unit, not at the page or layout. A product page is a server component; the add-to-cart button inside it is a client component. A dashboard is a server component; the chart with a hover tooltip is a client component.

• Data display, formatting, layout, and content — server components.
• Anything with onClick, onChange, useState, useEffect, or a browser API — client components.
• Forms — usually a small client component wrapping a server action.
• Third-party widgets — a thin client wrapper you own, loaded dynamically where possible.

What are the common mistakes?

1. 1Sequential awaits creating request waterfalls. Use Promise.all when requests do not depend on each other.
2. 2Passing non-serialisable props (functions, class instances, Dates in some cases) across the boundary — these throw at render time.
3. 3Fetching the same data in a parent and a child. Deduplicate with a shared cached function rather than prop drilling everywhere.
4. 4Leaking secrets: a server component can read process.env safely, but the moment that value is passed as a prop into a client component it is in the browser payload.

When are server components the wrong tool?

Highly interactive surfaces — a canvas editor, a spreadsheet, a real-time collaborative document — are client applications with a server behind them. Forcing them into a server-first structure adds ceremony without benefit. Use server components for the shell, authentication and initial data, and let the interactive core be a client island.

Similarly, if your data changes on every keystroke, the round trip to a server component is worse than a client fetch. Server components optimise for content that is stable within a request, not for per-interaction updates.