Chapter 44Lesson 2

Wiring the action prop

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

Last lesson you built a form with uncontrolled inputs, each carrying a name, whose values round-trip through FormData. In the previous chapter you built the createInvoice Server Action that takes that FormData. Both halves are finished; the connection between them is 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 incomplete on purpose so you don’t mistake the bare wiring for the finished pattern. The question underneath: what’s the minimum that connects the two, and why isn’t the answer fetch?

The `action` prop connects the form to the Server Action

Here is the entire connection. The first thing to notice 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>
  );
};

In real code every input still pairs with a <label>; they’re dropped here so the one new thing stands alone. That new thing is action={createInvoice}: you assigned the action’s function reference to the form’s action prop, and that 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, no hand-built request body. On submit, React reads the form’s named inputs, builds a FormData from them, and calls createInvoice(formData) for you. The values arrive because the inputs are uncontrolled: the DOM holds each one’s live value, and the DOM is exactly what the browser serializes on submit. Last lesson’s work is what makes this line so short.

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. The bridge is the import: when the client imports createInvoice, the compiler doesn’t ship the function body into the browser bundle but rewrites the import to an opaque action ID . The submit becomes an HTTP POST carrying that ID and the FormData. How the IDs rotate and how this is secured comes in a later chapter; for now, trust the bridge and keep your eye on the prop.

One contract makes it 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 happens when the form submits

action={createInvoice} reads like you handed React a function and it calls it. It does, but a lot happens between the click and the call. The handshake is invisible and instant, so here it is one beat at a time.

Browser React (client) Server