Chapter 44Lesson 2

Wiring the action prop

The React 19 form action prop, the one line that connects a native HTML form to a Server Action without onSubmit or fetch.

Last lesson you built a form whose inputs are uncontrolled, each carrying a name, and whose values round-trip through FormData for free. In the previous chapter you built the createInvoice Server Action that takes exactly that FormData. Both halves are finished, but the connection between them is missing, and it turns out to be a single prop. By the end of this lesson your form will submit to the action and clear itself for the next entry. It won’t yet tell the user it’s saving or show what went wrong, and we’ll leave it deliberately incomplete so you don’t mistake the bare wiring for the finished pattern. The question underneath is this: what’s the minimum that connects the two, and why isn’t the answer fetch?

The action prop is the whole wiring

Here is the entire connection, before any explanation of how it works. The first thing to absorb is how little there is.

'use client';

import { createInvoice } from './actions';

export const NewInvoiceForm = () => {
  return (
    <form action={createInvoice}>
      <input name="customer" type="text" />
      <input name="total" type="number" />
      <button type="submit">Create invoice</button>
    </form>
  );
};

That’s it. In real code every input still pairs with a <label>; they’re dropped here only so the one new thing stands alone. That one new thing is action={createInvoice}: you assigned the action’s function reference to the form’s action prop. That single assignment is the whole bridge.

Notice what you did not write. There’s no onSubmit, no event.preventDefault(), no fetch, no JSON.stringify, no Content-Type header, and no request body built by hand. On submit, React reads the form’s named inputs, builds a FormData from them, and calls createInvoice(formData) for you. The values arrive in that FormData because the inputs are uncontrolled: the DOM holds each one’s live value, and the DOM is exactly what the browser serializes on a submit. The work you did in the last lesson is what makes this line so short.

The last lesson named one requirement and deferred it, and here’s where it pays off: this form lives in a Client Component, so the 'use client' directive at the top is load-bearing. The action prop only wires up React’s submit interception inside a Client Component. A Server Component can pass an action down as a prop, but the <form> that consumes it renders client-side.

The action itself does not move to the client. createInvoice stays a Server Action, with 'use server' at the top of its own file, exactly as you left it. The bridge is the import. When the client imports createInvoice, the compiler doesn’t ship the function body into the browser bundle; it rewrites that import to an opaque action ID . Under the hood the submit becomes an HTTP POST carrying that ID and the FormData. You saw this seam from the server side in the previous chapter; here it runs to completion from the client. How the IDs rotate and how it’s secured is the subject of a later chapter. For now, trust the bridge and keep your eye on the prop.

Notice the contract that makes it all fit with no glue. The input names, the FormData keys, and the schema keys are one set of strings. That’s why the action can open with Object.fromEntries(formData) and parse the result without the form knowing anything about the schema: both were written against the same names.

What React does on submit

action={createInvoice} reads like you handed React a function and it calls it. That’s true, but a lot happens between the click and the call, and seeing those steps is what replaces the fetch mental model with the platform’s. In practice the handshake is invisible and instantaneous, so let’s slow it down and step through it one beat at a time.

Browser React (client) Server