Server Component Serialization
Values crossing a Server Component to Client Component boundary must be representable by the React Server Components protocol. The boundary is not equivalent to ordinary JSON serialization, so some JavaScript values can cross even though functions and arbitrary class instances cannot.
In React Server Components, a Server Component can render a Client Component by supplying props across the server/client boundary. Those props are encoded by the React Server Components transport protocol, commonly called Flight, rather than being sent as an unrestricted JavaScript object.
Serializable values include common primitives, arrays, plain objects, and several protocol-supported JavaScript values. The exact supported set depends on the React implementation and version, so an interview answer should distinguish protocol support from the simpler rule of "JSON-compatible values."
Functions generally cannot be passed from a Server Component to a Client Component as ordinary props because a server function is not itself a client-side function value. React does support a separate mechanism for explicitly exposed Server Functions, where the client receives a reference that can invoke server-side code rather than receiving the original function implementation.
The boundary matters because Client Components are still part of a client-side module graph, while Server Components execute on the server. Data crossing the boundary must therefore have a representation that the RSC transport understands and can reconstruct on the receiving side.
A useful debugging approach is to identify the boundary first, then inspect the value being passed. If a prop fails serialization, replace it with data rather than behavior, or use the framework's supported server-function mechanism when the requirement is to trigger server-side work.
Key points
- Props crossing an RSC server/client boundary must be supported by the React Server Components protocol.
- The protocol is broader than plain JSON serialization for some JavaScript values.
- Ordinary functions are not transferable as client-side function implementations.
- Server Functions use a distinct reference-based mechanism rather than serializing function code.
- Keep the boundary data-oriented and verify unusual values against the React version in use.
Interview questions
What does it mean for a prop to be serializable across a Server Component boundary?
It means React's Server Components transport can encode the value on the server and reconstruct an appropriate representation on the client. Common primitives, arrays, and objects are typical examples. The important point is that this is an RSC protocol constraint, not simply a rule about TypeScript types. A value can have a valid TypeScript type and still be unsuitable for the boundary.
Why can't you normally pass a function from a Server Component to a Client Component?
A normal function contains server-side executable behavior, while the Client Component needs something meaningful in the browser. React does not serialize arbitrary function implementations into client JavaScript through ordinary props. If the intended behavior is to invoke server-side code, React's Server Function mechanism provides a different kind of reference. That mechanism should not be described as transferring the function itself.
Is RSC serialization the same thing as JSON serialization?
No. RSC has its own wire protocol and value model. JSON is useful as an intuition for ordinary data, but it does not describe every value supported by React Server Components. For precise claims, use the supported-value rules for the React version being discussed.
How would you debug a serialization error at a Server/Client boundary?
First, identify the exact Server Component to Client Component boundary and the prop that crosses it. Then reduce the value to basic data and determine whether the problematic value is a function, class instance, resource handle, or another unsupported runtime object. If server-side behavior is required, consider whether a Server Function is the appropriate abstraction instead of passing a callback. Finally, verify the precise supported-value rules for the React and framework versions in use.