A Next.js Server Action deletePost needs the id of the post to delete, but that id is not one of the form's inputs. When the action is wired to <form action={...}>, what are your options for getting the id to it, and what is the tradeoff of each?

## Why this comes up at all When you write `<form action={deletePost}>`, the framework calls your function with exactly one thing: a `FormData` object built from the form's named controls. That is a narrow channel. Real mutations usually need context the user never typed — a record id, a workspace slug, a revision number — and none of that is a form field. So every team hits the same question in the first week: how do I get an extra argument in? ## Option 1 — bind the argument `Function.prototype.bind` produces a new function with leading arguments pre-applied, and that works on a Server Action: ```tsx import { deletePost } from './actions' export function DeleteButton({ id }: { id: string }) { const deleteThisPost = deletePost.bind(null, id) return ( <form action={deleteThisPost}> <button type="submit">Delete</button> </form> ) } ``` The action's signature becomes `(id: string, formData: FormData)` — the bound value first, the form data last: ```ts 'use server' export async function deletePost(id: string, formData: FormData) { // ... } ``` The first argument to `bind` is the `this` value, which is irrelevant for a Server Action, hence the conventional `null`. The bound value is not rendered as a form control, so it is not something the user edits in a dev-tools panel by tabbing to a field. Bound values must be serializable, exactly like any other argument crossing the boundary. ## Option 2 — a hidden input ```tsx <form action={deletePost}> <input type="hidden" name="id" value={post.id} /> <button type="submit">Delete</button> </form> ``` and inside the action, `const id = String(formData.get('id'))`. This is the most obvious approach and it is perfectly workable, but it has two honest downsides. The value is part of the rendered HTML, plainly readable in view-source. And a hidden input is still an input: changing its value before submitting takes seconds in the browser's element inspector. Note also the type story. Everything that comes out of `FormData` is a string or a `File`. `formData.get('quantity')` is `"3"`, never `3`, and a missing key returns `null` rather than `undefined`. Bound arguments keep the type you bound them with, which is one small ergonomic advantage. ## Option 3 — close over the value When the form is rendered by a Server Component, an inline action can simply reference the value in scope: ```tsx export default async function Page({ params }) { const { id } = await params async function deletePost() { 'use server' await db.post.delete({ where: { id } }) } return <form action={deletePost}><button>Delete</button></form> } ``` This reads the best of the three. Closed-over values still have to reach the browser so the right call can be reconstructed, and Next encrypts them on the way out, so unlike a hidden input they are not readable in the page source. ## The rule that outranks all three None of this makes the value trustworthy. Bound, hidden or closed over, the id makes a round trip through a browser you do not control, so the action is the place where ownership and permission are established — every one of these options is a convenience for *passing* data, never a proof of *who* sent it. ## Choosing Prefer a closure when the form is rendered on the server and the action is local to it — it is the least ceremony. Prefer `bind` when the action lives in a shared module and the form is rendered by a client component. Reach for a hidden input when the value genuinely is part of the submitted document (a selected variant, a chosen tab) and you would be validating it anyway. Avoid stuffing structured objects into hidden inputs as JSON strings; that is a sign the argument wants to be bound instead.