The serialization boundary: use client splits the module graph

A directive on a module, not a flag on a component

'use client' goes at the top of a file, and it means: from here on, this module and everything it imports, transitively belong to the client bundle. It is a graph cut, not a component property. Mark a 40-line Tabs.tsx and you have not added 40 lines to the bundle — you have added Tabs.tsx plus its imports, plus their imports, until the graph bottoms out. One careless import { format } from "../lib/format" where format.ts pulls a charting utility pulls the chart library too. This is also why a server component imported by a client file silently becomes a client component: there is no marker on the component itself, only its position in the graph relative to the nearest 'use client' cut. The corollary discipline: keep client files small and leaf-like, and treat every import added to one as a bundle-size and secrecy decision.

The defensive tool for the secrecy half is the server-only package: import it in any module that must never reach the client (db.ts, config.ts, anything touching process.env), and the build fails the moment some refactor drags that module across the cut. It costs one import line and converts a silent leak into a compile error. The mirror package client-only exists for modules that must never run server-side.

What may cross: the serialization rules

Props passed from a server component to a client component are serialized into the Flight payload. The allowed list is wider than JSON but strict: primitives (string, number, bigint, boolean, undefined, null, symbols only via Symbol.for), plain objects and arrays, Date, Map, Set, TypedArrays and ArrayBuffer, FormData, JSX produced by server components, Promises (the client unwraps them with use() — this is how streaming data crosses), and references to server functions. The rejected list is what defines the architecture: functions (other than 'use server' functions), class instances (anything whose prototype is not Object.prototype — an ORM entity, a Temporal object, your domain model), and unregistered symbols. A rejected value throws at render time with a serialization error naming the prop.

The dangerous case is the one that does not throw. Most ORMs return plain objects — so a full database row sails through serialization and lands, column by column, in a payload any user can read. The Hook’s passwordHash leak is this exact shape. When you review a PR that passes a model object as a prop, ask yourself: which columns am I comfortable publishing to anyone with view-source? The rule that survives audits: treat the server→client prop surface as a public API. Map rows to explicit DTOs at the boundary — { id, name, avatarUrl } — the same way you would never return SELECT * from a public endpoint.

Interleaving without importing: the children pattern

The graph cut seems to imply that anything below a client component must be client too — it does not, and the escape hatch is the oldest prop in React. A client component may not import a server component, but it can receive server-rendered output as children (or any JSX-typed prop), because server-rendered JSX is on the serializable list:

// Tabs.tsx — 'use client': owns activeTab state, ~2 kB
export function Tabs({ children }: { children: React.ReactNode }) {
  const [active, setActive] = useState(0);
  return <div>{/* tab headers */}{children[active]}</div>;
}

// page.tsx — server component
<Tabs>
  <ReportPanel data={await db.reports.q3()} />   {/* stays server */}
  <AuditPanel rows={await db.audit.recent()} />  {/* stays server */}
</Tabs>

The panels render on the server — direct database access, zero bundle weight — and arrive inside the payload as already-resolved trees; Tabs just decides which one to show. The composition rule in one line: the importer determines the environment, the renderer does not. A client shell holding server children is the workhorse layout of every serious RSC codebase, and reaching for it is what separates a surgical 'use client' leaf from the page-level directive that drags a whole route into the bundle.

The reverse channel: server functions

Data flows server→client through props; the only sanctioned way back is a server function. Mark a function (or a whole module) with 'use server', and React replaces it, in the client bundle, with a serializable reference; calling it from the browser issues a POST under the hood, with arguments serialized by the same Flight rules and the return value streamed back. Two production consequences follow directly. First, every server function is a public, unauthenticated-by-default endpoint — the framework wires the route for you, and an attacker does not need your UI to call it; validate and authorize inside the function, every time, as you would any handler. Second, the argument and return types obey the same serialization rules as props — no class instances in, no class instances out — so the DTO discipline applies in both directions.