Props Serialization Constraints

The advice you will hear is "props must be JSON." It is half right and fully misleading. Server → Client props are serialized by React's Flight protocol, which carries more than JSON — and rejects things JSON would happily mangle. This is the enforcement layer of the boundary you drew in Crossing the Client Boundary: props are the only channel between the two environments, and the protocol decides what fits through it.

Here is the table to memorize; it is what React itself documents as serializable:

Each "No" has a specific message, and quoting them in an interview signals you have actually hit them:

Event handlers cannot be passed to Client Component props.
If you need interactivity, consider converting part of this to a Client Component.

Functions cannot be passed directly to Client Components unless you
explicitly expose it by marking it with "use server".

Only plain objects, and a few built-ins, can be passed to Client Components
from Server Components. Classes or null prototypes are not supported.

Only global symbols received from Symbol.for(...) can be passed to Client
Components. The symbol Symbol.for("myTag") cannot be found among global symbols.

That last one hides a real production trap: null-prototype objects. Some ORMs hand back rows whose prototype is null (you can see it in console.inspect output as [Object: null prototype]), and React rejects them even though they are "plain" by every other definition. Dev builds additionally warn from the server console: Only plain objects can be passed to Client Components from Server Components. X objects are not supported. The fix is one line at the fetch boundary, before the data ever approaches a prop:

const rows = rawRows.map((r) => ({ ...r }));  // normal Object.prototype

Two asymmetries with JSON complete the picture. Flight preserves undefined props where JSON.stringify silently deletes them, and it revives Date as Date where JSON coerces it to a string. So if you see Reason: object ("[object Date]") cannot be serialized as JSON. Please only return JSON serializable data types. you are not looking at an RSC prop at all — that is the older Pages Router / getServerSideProps JSON check, a different boundary with different rules. Knowing which encoder ran tells you which rulebook applies.

Finally, a Date that crosses intact can still embarrass you: the server and the browser may sit in different time zones, so formatting the prop with toLocaleString() during SSR and again after hydration can produce different strings — React 19 reports it as a hydration mismatch. Compute locale-dependent formatting after mount, or format to a fixed zone on the server.

The single most common App Router failure is a callback written in server code and handed to something that crosses the boundary. Two signatures, one cause.

Signature 1 — an on* prop. A server page.tsx renders <button onClick={...}>, or passes onClick into a client <Button>:

Error: Event handlers cannot be passed to Client Component props.
  <button onClick={function} children=...>
         ^^^^^^^^^^^^^^^^^^^^^
If you need interactivity, consider converting part of this to a Client Component.

Signature 2 — any other function prop. Passing formatter={formatPrice} from a server component yields Functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with "use server". (and if you accidentally return a component reference instead of JSX, React adds Functions are not valid as a child of Client Components.)

Why the wall exists: a function is a live closure over this process. It captures database handles, request-scoped values, maybe secrets. There is nothing to encode — a reference like formatPrice means nothing in the browser, and shipping the closure would ship your backend. Serialization is your security boundary as much as a technical one.

Fix 1 — move the behavior down. The client defines its own handler and receives only data:

// server page: passes data, not behavior
<DeleteButton itemId={item.id} />

// DeleteButton.tsx
'use client';
import { useTransition } from 'react';
import { removeItem } from '../app/actions';

export function DeleteButton({ itemId }) {
  const [pending, start] = useTransition();
  return (
    <button disabled={pending} onClick={() => start(() => removeItem(itemId))}>
      {pending ? 'Deleting…' : 'Delete'}
    </button>
  );
}

Fix 2 — the escape hatch. A Server Function marked 'use server' is serializable: React replaces it with an endpoint ID and the client invokes it over the wire. So a server component may pass an action where it could never pass a callback:

// server component — legal, because removeFromCart is a Server Function
<CartClient onRemove={removeFromCart.bind(null, cartId)} />

bind matters: bound arguments are serialized eagerly, so the payload carries them once, up front. Note where this does not apply: <form action={serverAction}> rendered by a server component is the blessed path — that action prop accepts a Server Function precisely because what crosses is a reference, not code. The symmetry to hold onto — Server Function arguments and return values obey the same table as props, because they travel the same protocol. A Date argument survives; a class instance return value throws the moment it re-crosses.

Promises deserve their own note because they invert the intuition. An unresolved promise is on the allowed list: the server starts the work, sends a reference, and the client component suspends on it with React 19's use() while the value streams in:

'use client';
import { use } from 'react';
export function Reviews({ reviewsPromise }) {
  const reviews = use(reviewsPromise);   // suspends until the row arrives
  return <List items={reviews} />;
}

Three caveats keep this pattern honest: the resolved value must itself be serializable; the promise must have a stable identity across re-renders (create it in the server component and pass it down — a promise constructed inline in client render re-suspends on every render, showing the fallback forever); and rejection surfaces as an error, so wrap the consumer in an Error Boundary as well as <Suspense>. In interview terms: await on the server, use() on the client, serialize everything in between — and that flow continues with route segments in Dynamic Route Segments.

Your data leaves the server through two different doors, and they do not agree on types. Props cross inside the streamed RSC payload (Flight). Route handlers and your own fetch calls cross as JSON. Predicting each type in both encodings is the difference between a design that works and data that quietly disappears.

Read the right column twice: JSON fails silently, Flight fails loudly. A prop mistake interrupts rendering with a message naming the offending value; a route-handler mistake ships {} to a client that calls .get() on it two screens later. When an interviewer asks which is more dangerous, that is the answer — loud boundaries are features.

Loud does not mean instant, though. Statically rendered routes evaluate their props during next build's prerender step, so the error lands in CI; dynamic routes throw on the first request instead. In development the error overlay and the server console both point at the prop's path inside its parent object, which is usually enough to find the offending field without a debugger.

The second cost of props is size: everything you pass is embedded in the document. Open view-source on any App Router page and you will see the payload streaming in as self.__next_f.push(...) chunks — your prop data, inlined, then parsed and re-inflated during hydration. Pass a 10,000-row array to a client table and you have added roughly a megabyte of serialized JSON to the HTML, plus ten thousand React elements for the browser to reconcile — and the router caches payloads, but the first delivery still costs those bytes on the critical path. The fix is architectural, not cosmetic:

Keep the dataset server-side.  Pass what is interactive, not what is displayed.
  1. Server-render the rows; pass only expanded-row ids and the visible window
  2. Paginate/filter on the server; let the island request pages via an action
  3. Aggregate before crossing — pass 30 chart points, not 30,000 events
  4. Measure: compare document size and hydration time before/after

A useful split of responsibilities: the server owns volume (queries, joins, filtering, formatting), the boundary owns only the state the island genuinely mutates — open: Set<string>, page: number, selectedId: string. Small state, small props, fast hydration.

The interview close for this topic is one sentence plus one example: props crossing to Client Components must be serializable because the protocol is a streamed data format, not a function channel — so functions, class instances, and local symbols throw with named errors, while Date, Map, Set, BigInt, and promises ride through intact; when something cannot cross, either plainify it at the fetch boundary or move the behavior behind a 'use server' function and send only data.