A React Server Component renders `<SaveButton onSave={() => saveRow(id)} />`, where SaveButton is a Client Component, and the render fails with an error about functions. Why does React reject that prop, and what are the legitimate ways to give that button behaviour?

## What the error is actually telling you When a Server Component renders a Client Component, React does not call the client component. It emits a description into the RSC payload: which client chunk to load, and what props to give it. The browser downloads that payload and instantiates the component there. So the props are values that must survive being written out in one process and read back in another. An arrow function fails both halves. Its body is code that lives only in the server bundle — the client bundle never received it. And it closes over server-side scope: `id`, `saveRow`, a database handle, a request-scoped variable. Even if React could ship the source text, the closure it captured has no meaning in the browser. React therefore raises an error at server render time, roughly "functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with 'use server'", and it names the prop. ## Fix 1 — behaviour belongs to the client module This is the right answer most of the time. The client component owns its interactivity; the server component supplies the data it needs to act. ```jsx // SaveButton.jsx 'use client'; import { saveRow } from './client-api'; export default function SaveButton({ id }) { return <button onClick={() => saveRow(id)}>Save</button>; } ``` The server component now renders `<SaveButton id={row.id} />`. Only a number crosses. Notice what changed conceptually: the server stopped trying to inject behaviour and started supplying parameters. ## Fix 2 — a Server Function crosses as a reference Sometimes the behaviour genuinely has to run on the server: it touches the database, uses a secret, or must not be reimplemented in the client bundle. That is what Server Functions are for. A function defined in a module with a top-level `'use server'` directive, or defined with an inline `'use server'` directive inside a Server Component, becomes passable as a prop. ```jsx // actions.js 'use server'; export async function saveRow(id) { await db.rows.update(id, { saved: true }); } ``` ```jsx // Server Component import { saveRow } from './actions'; import SaveButton from './SaveButton'; export default function Row({ id }) { return <SaveButton id={id} onSave={saveRow} />; } ``` What crosses is not the code. React serializes an opaque reference — an identifier the runtime can map back to that function — and the client receives a callable stub. Invoking it from the browser sends a request to the server, which runs the real function and returns its (serializable) result. The mental model to state out loud: a Server Function prop is an RPC endpoint handle, not a copied closure. Two consequences worth naming. The arguments you pass and the value returned obey the same serialization rules as props, so you can pass an id or `FormData` but not a callback. And because it is invokable from the browser, it is a network-reachable entry point — validate its inputs and re-check authorization inside it rather than assuming the caller is your own UI. ## Fix 3 — bind on the server, still a Server Function If a handler needs data the client should not carry, you can produce a specialised Server Function on the server — for example by calling `.bind(null, id)` on an imported Server Function — and pass that. The bound arguments are serialized as part of the reference, so this is still a data-crossing operation, not a closure-crossing one. ## The distinction interviewers are probing Candidates who have only written client React think of props as arguments to a function call, so passing a callback down is reflex. The question exists to see whether you have internalised that this particular parent/child pair sits on two sides of a network hop. Once you say "the boundary is a serialization boundary; behaviour cannot be serialized unless it is exposed as a callable endpoint", every other case — class instances, symbols, promises — follows from the same sentence. ## What does *not* fix it Wrapping the function in an object, in an array, or behind a getter does not help — serialization is recursive. `useCallback` is irrelevant; it is a client hook and the problem is not identity stability. Stringifying the function and `eval`-ing it on the client is not a serious answer and gives away that the model has not landed.