In a Next.js Server Component you define an inline 'use server' action that closes over a value computed during render, and pass it to a form. Where does that captured value live between render and the moment the user submits, and what does that imply about what you may close over?

## The question behind the question Inline actions read like ordinary JavaScript closures: ```tsx export default async function Page({ params }: { params: Promise<{ id: string }> }) { const { id } = await params const post = await db.post.findUnique({ where: { id } }) async function publish() { 'use server' await db.post.update({ where: { id: post.id }, data: { published: true } }) } return <form action={publish}><button>Publish</button></form> } ``` But the render and the submit are two separate HTTP requests, potentially minutes apart and potentially served by different machines. Nothing in the server process is holding `post` for you. So where did it go? ## Closures become bound arguments When Next compiles an inline action, it rewrites the captured variables into leading parameters of the underlying server function and *binds* the current values at render time. Those bound values are serialized into the RSC payload that goes to the browser along with the action's id. When the form submits, the browser POSTs the id, the bound values and the form data; the server resolves the id, unpacks the bound values and calls the real function with them. The explicit spelling of the same mechanism is `Function.prototype.bind` against a module-level action: ```tsx // app/actions.ts 'use server' export async function publishPost(id: string) { /* ... */ } ``` ```tsx // in a Server Component <form action={publishPost.bind(null, post.id)}> <button>Publish</button> </form> ``` This is not a different feature. It is the same transport, written where a reviewer can see it — which is a good reason to prefer it when the captured value matters. ## Consequence one: serializability Because the value crosses the network twice, it must be serializable by React's serialization. Strings, numbers, booleans, `null`, plain objects and arrays of those, `Date`, `Map`, `Set`, typed arrays, promises and other server functions travel; a Prisma client, a class instance with methods, a function that is not itself a server function, or a whole ORM row carrying lazy accessors does not. Capturing a large object also inflates every page that renders it — a list of 200 rows that each capture the full row rather than `row.id` pays for 200 serialized rows in the HTML. The practical rule is to close over an **identifier**, not an entity: `post.id`, not `post`. ## Consequence two: trust This is the part senior candidates are expected to reach. The bound value is not server state that the client happens to trigger; it is data the client is holding and returning. Next encrypts bound arguments, so the value is not sitting in the page source in plaintext and a user cannot trivially rewrite it — but encryption is a confidentiality and tamper control on a value that has still left your server. Two rules follow: - **Never close over a secret.** An API key, an internal connection string, a signed token you did not intend to expose, a flag that means "this caller is an admin" — none of these should ride in a closure. Read them inside the action body instead, where they never leave the server. - **Never let a closure carry the authorisation decision.** "I only rendered this action for owners, so `ownerId` in the closure proves ownership" is not an argument the runtime supports. The action is an endpoint; whatever it needs to establish about the caller it establishes in its own body, from the request context, at invocation time. ## Consequence three: deployment Because the bound values are encrypted, decryption must succeed on whatever machine receives the POST. Next derives an encryption key at build time; in a deployment with several instances they must all be running the same build, or share the key explicitly through configuration, otherwise a payload produced by one build fails to decrypt on another and the action errors. The same class of problem hits an old tab during a rolling deploy: the page in the browser was rendered by the previous build, and the ids and bound payloads it holds may not be valid against the new one. Design mutations to fail visibly and be retryable rather than to silently half-apply, and expect a stale client to need a reload. ## What to say in an interview Summarise it as: *inline closures are bound arguments that round-trip through the client, encrypted but not server-resident; capture ids, never secrets, and re-establish trust inside the action*. Then mention `.bind` as the readable equivalent. This behaviour is what Next.js 16 does, and it has been the model since Server Actions stabilised in Next.js 14.