React Server Components: the boundary, the payload, and what crosses it

Components that never ship

Why does any of this matter? Every KB your client downloads must be parsed and executed before the page is interactive — and most of a typical Next.js codebase is rendering logic that never needs to run in the browser at all. RSC lets you draw that line explicitly and pay nothing for crossing it.

A React Server Component is a component that executes only on the server — at build time or request time — and whose code is never included in the client bundle. That second clause is the entire economic argument. A classic SSR component renders on the server and then again on the client during hydration, so its code ships twice-used but once-downloaded; an RSC renders once, server-side, and the browser receives only its output. The component can therefore do things browser code never could: query the database directly, read the filesystem, use a heavyweight markdown renderer or syntax highlighter, hold API secrets — none of it leaves the server.

// app/orders/page.tsx — a Server Component (the default in app/)
import { db } from "~/lib/db";          // server-only: never bundled for the client
import { formatMoney } from "~/lib/money";

export default async function OrdersPage() {
  // Data fetching co-located with the component that needs it.
  // No useEffect, no loading-state dance, no API route in between.
  const orders = await db.order.findMany({ take: 50, orderBy: { createdAt: "desc" } });

  return (
    <table>
      <tbody>
        {orders.map((o) => (
          <tr key={o.id}>
            <td>{o.customerEmail}</td>
            <td>{formatMoney(o.totalCents)}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

Note what’s absent: no useEffect + fetch + loading spinner, no API endpoint built solely to ferry data to the browser. The component is async, it awaits its own data, and the data layer is co-located with the markup that consumes it. This kills the classic client-fetching waterfall where the browser downloads JS, runs it, then discovers it needs data, then makes another round trip — on the server, component and database are often in the same datacenter, and that round trip is ~1ms instead of ~100ms.

What the client actually receives is the RSC payload: a compact serialized description of the rendered tree — the HTML-shaped output of server components, plus placeholders (“render the client component from chunk X here, with these props”) wherever a client component appears. React on the client consumes this payload to construct the tree without re-running any server code. This is also what makes soft navigation work: clicking a link fetches the new route’s RSC payload, and React merges it into the existing tree — client components in the persistent layout keep their state (your half-typed search box survives navigation), because the payload is a description to reconcile, not an HTML page to replace.

”use client” is a boundary, not a marker

The most common senior-level misreading of RSC: treating "use client" as “this component is a client component.” What the directive actually declares is a boundary in the module dependency graph: this file, and everything reachable through its imports, belongs to the client bundle. You don’t annotate every interactive component — you annotate the entry points where the server tree hands off to client territory, and the bundler walks the import graph from there. That’s why the Hook’s one-line “fix” pulled 180KB across: marking a layout file marks its entire import subtree.

Two consequences follow. First, the practical pattern is push client boundaries to the leaves: keep layouts, pages, and data-heavy components as server components, and carve out the smallest interactive islands — <AddToCartButton>, not <ProductPage>. Second, a client component cannot import a server component (importing would drag server code into the client graph — the build will treat that import as a client component, or fail on server-only APIs). But a client component can receive server-rendered content as children or any other prop: the server renders the inner tree, and the client component slots the already-rendered result into place. Interleaving is done by composition, not by import.

// theme-provider.tsx
"use client";
export function ThemeProvider({ children }: { children: React.ReactNode }) {
  const [theme, setTheme] = useState<"light" | "dark">("light");
  return <ThemeCtx.Provider value={{ theme, setTheme }}>{children}</ThemeCtx.Provider>;
}

// app/layout.tsx — Server Component
export default function RootLayout() {
  return (
    <ThemeProvider>
      {/* Still server-rendered, zero client JS — passed THROUGH the
          client component as children, not imported by it. */}
      <HeavyServerSidebar />
    </ThemeProvider>
  );
}

What may cross: serializable props only

When you define a prop on a server component and pass it down to a "use client" component, ask yourself: could this value survive being written to JSON, sent over the wire, and revived in a completely separate process hours later? If the answer is no, the prop cannot cross.

Props flowing from a server component into a client component cross a real process-and-time boundary — they are serialized into the RSC payload on the server and revived in the browser. So they must be serializable by React’s RSC serializer: JSON-style primitives, plain objects and arrays, Date, Map/Set, FormData, typed arrays, JSX, and promises (which stream in as they resolve). What cannot cross: functions (an onClick closure has captured server scope — there is no way to revive it in a browser), class instances (a Prisma model object will throw or silently lose its prototype), and anything carrying live resources like sockets or DB handles. This is why “Functions cannot be passed directly to Client Component props” is a boundary error, not a syntax error — and why the two legitimate escape hatches are shaped the way they are: pass data down and let the client component own the handler, or pass a Server Action (a function marked with "use server"), which is serializable precisely because what crosses the wire is a reference — an ID the client can invoke via a network call — never the closure itself.

The same boundary explains why hooks and state are impossible in server components. useState presumes an instance that survives re-renders and receives events over time; a server component executes once per render request and is gone — there is no second render for state to persist across, no event loop listening for clicks, no lifetime. useEffect presumes a DOM to affect; there isn’t one. The rule “no hooks in server components” isn’t a framework limitation to be patched later — it falls directly out of what a server component is: a function of data to output, executed in an environment with no interactive lifetime.