Half-Controlled Forms Silently Revert on Resubmit

The short version

Control only some of a form’s inputs, and a screen returned by a validation error keeps the controlled fields while the uncontrolled ones revert silently to defaultValue. The form looks fine, so it gets resubmitted.

In the ad-slot create/edit form, capacity, price and term were controlled with useState while the slot name, published setting and others stayed on defaultValue. A screen returned by a validation error ended up in a state where “capacity and price are still there, but the slot name and published setting are back at their defaults.”

What it looks like

This form is shared between create and edit and submits through React 19’s <form action={fn}>. An earlier commit had put the three groups — capacity, price and term — into a plan state, controlled with value and onChange. The slot name, description, scope, start month, published setting and video-allowed remained uncontrolled inputs, given only a defaultValue for the initial render.

When a validation error returns from updateLoop / addLoop — a failed v2 lookup while saving a slot pinned to a specific monitor, say — capacity, price and term stay on screen as entered. But the slot name, description, scope, start month, published setting and video-allowed had reverted to their defaultValue, whatever had been entered before submitting. This is worse than a design where everything resets, because some fields (capacity, price) look alive, so the form itself looks normal and it is easy to glance at the red error message and press save again. A slot someone meant to unpublish can be resubmitted with the published setting back at its default, and saved published.

Why

React 19, on <form action={fn}> submit, resets uncontrolled inputs whether it succeeded or failed. Only capacity, price and term were controlled with value + onChange, with the rest left on defaultValue, because the immediately preceding commit had addressed only the “capacity and price vanish on remount” problem and had not touched the other fields.

// before the fix: only capacity, price and term held in state
const [plan, setPlan] = useState({
  planKind: loop?.planKind ?? "",
  capacity: String(loop?.capacity ?? 10),
  slotSeconds: String(loop?.slotSeconds ?? 30),
  termFee: num(loop?.termFee),
  monthlyFee: num(loop?.monthlyFee),
  termMonths: String(loop?.termMonths ?? 12),
  maxTermMonths: num(loop?.maxTermMonths),
  cardOnly: !!loop?.cardOnly,
});

The slot-name <input> was given defaultValue={loop?.label ?? ""} rather than value={draft.label}, and had no onChange. React treats it as an uncontrolled input, which makes it a reset target on every submit.

Fixing it

We merged every input in the form — slot name, description, scope, start month, published setting and video-allowed included — into a single draft state (renaming the state from plan to draft, since it now holds fields beyond the pricing plan).

const EMPTY_DRAFT = {
  label: "",
  description: "",
  scopeRef: "",
  startMonth: "",
  planKind: "",
  capacity: "10",
  slotSeconds: "30",
  termFee: "",
  monthlyFee: "",
  termMonths: "12",
  maxTermMonths: "",
  cardOnly: false,
  published: false,
  allowVideo: false,
};

const [draft, setDraft] = useState({
  label: loop?.label ?? "",
  description: loop?.description ?? "",
  scopeRef: loop?.scopeRef ?? "",
  startMonth: loop?.startMonth ?? "",
  // ...pricing-plan fields unchanged
});

The pricing-plan preset button (applyPreset) used to overwrite the whole object starting from the initial value (EMPTY_PLAN). Switching that shape to start from EMPTY_DRAFT would wipe the slot name and published setting already entered the moment the preset was pressed. So we changed it to overwrite only the eight pricing-plan fields on top of the current draft.

const applyPreset = (kind: "gakka" | "shinro") =>
  setDraft((d) => ({
    ...d,
    planKind: kind,
    slotSeconds: "30",
    termMonths: "12",
    maxTermMonths: "",
    monthlyFee: "",
    ...(kind === "gakka"
      ? { capacity: "5", termFee: "200000", cardOnly: false }
      : { capacity: "30", termFee: "10000", cardOnly: true }),
  }));

Preventing a repeat

A test guarding against this bug already existed, but its assertion was the negative “there is no defaultValue”. With that assertion, an input carrying neither value nor onChange — a field nobody ever rewrote — slips through. We rewrote it to require being controlled positively, checking that each field has both value (or checked) and onChange. hidden inputs, which exist only to carry a current value along, were excluded from the check.

That test is also implemented by slicing the string between the two function definitions LoopForm and LoopCard and inspecting it. Reorder the functions and the slice becomes an empty string, so the whole check passes having looked at nothing. We therefore also assert, as a precondition of the test, that LoopCard is defined after LoopForm.

An uncontrolled input is certainly not a bug in itself. But as long as <form action> is used, controlling only part of a form produces the asymmetric behaviour “on resubmit after a validation error, only the uncontrolled fields silently revert”. Treating every input in a form the same way — all controlled, or all left on defaultValue — makes this kind of break, the kind that looks normal, easier to avoid.

On the same ad-slot admin screen, the story of a UI restriction the server never checked is in A UI freeze not enforced server-side is rewritable by a forged POST.