React forms rarely fail because the input element is difficult. They fail when several parts of the product make a decision at the same time: validation says one thing, the network request says another, and the UI still has an old error on screen.

I have found a useful fix in both JavaScript and TypeScript projects: give the form one typed decision boundary. The component should receive one state, decide what the user can do next, and leave network effects to a separate layer. This makes a feature feel faster because it is more predictable, even when the server is not.

The real problem is an unowned decision

The usual starting point looks harmless:

const [isLoading, setIsLoading] = useState(false); const [hasError, setHasError] = useState(false); const [isComplete, setIsComplete] = useState(false);

After a few product requests, these booleans can describe states that should never exist. Is a completed form still loading? Should the old error stay visible while a retry runs? Can the user click submit twice while the first request is waiting?

The goal are not fewer lines of state. The goal is one place where the product decision is obvious. If a user can either edit, submit, retry, or continue, those choices belong in a model that makes the valid next action clear.

Model the boundary with a discriminated union

Start by naming states after user-visible behavior rather than implementation details:

type FormState = | { kind: "editing"; values: Values; fieldErrors: Record<string, string> } | { kind: "submitting"; values: Values } | { kind: "success"; reference: string } | { kind: "failure"; values: Values; message: string; retryable: boolean };

This gives React and the developer the same contract. A success state cannot accidentally render a retry button that expects a set of editable values. A submitting state carries a snapshot, so a late response does not silently overwrite newer edits.

The union is also a small form state machine. Events can be explicit, too:

type FormEvent = | { type: "edit"; values: Values } | { type: "submit" } | { type: "resolved"; reference: string } | { type: "rejected"; message: string; retryable: boolean };

That extra naming feels a bit formal at first, but it removes guesswork when the feature grows. A reducer can reject an invalid transition instead of making every click handler remember every boolean combination.

Keep effects outside the render decision

The component should render from state and dispatch events. A hook or service should perform the request. This separation keeps a network response from becoming an invisible UI rule.

function SubmitPanel({ state, dispatch }: Props) { switch (state.kind) { case "editing": return <Editor values={state.values} onSubmit={() => dispatch({ type: "submit" })} />; case "submitting": return <p role="status">Saving your changes…</p>; case "success": return <p role="status">Saved. Reference: {state.reference}</p>; case "failure": return <ErrorPanel message={state.message} canRetry={state.retryable} />; } }

The status message is part of the feature, not decoration. Disable only the action that cannot safely run, preserve useful input on failure, and move focus when the next step changes. These small choices make the form more accessible and also reduce support questions.

Test transitions and user-visible promises

Test the transitions rather than only checking that a button exists. A good test asks what happens when a user submits, edits while a request is pending, receives a validation error, or retries after a timeout.

For example, the test should prove that a second submit is ignored while submitting is active and that a failed request returns the original values. It should also check the role="status" or role="alert" message, because that is the promise the user actually receives.

For automated workflows, an execution envelope can make each run easier to inspect: an execution envelope for automation. For verification-specific fixtures, the same ownership idea applies to an email lease for verification tests. The form does not need to know how the test inbox is provisioned; it only needs a reliable state transition.

Use the boundary for email verification flows

Email verification is a good stress test for this design. The flow often has idle, sending, waiting, verifying, expired, and verified states. Modeling them separately prevents a resend timer from accidentally enabling the submit action, or an expired code from showing a success message.

In a test environment, a free disposable email can help isolate a run from a developer's real inbox. Keep that concern at the fixture boundary, with a clear cleanup rule. A typo such as “tem email” in a test note or “tempail mail” in a search term should not leak into the state names; readable product language still matters.

A practical shipping checklist

Before merging a form, ask:

  1. Can every visible state be named without referring to a boolean combination?
  2. Does each async response belong to the request that started it?
  3. Are invalid actions disabled or ignored at one boundary?
  4. Does failure preserve enough information for a useful retry?
  5. Do tests cover success, failure, expiry, and a repeated click?
  6. Can a screen reader understand what changed?

This approach is not about adding ceremony to every input. It is about making the important decision explicit. When a React feature has one typed boundary, the UI, tests, and product behavior are talking about the same thing. That makes the next change more clear, and shipping gets a little less scary.