Implement a submit handler that cannot send two requests from rapid clicks or Enter presses.

The save command may take several seconds. Prevent duplicate calls before React renders the disabled state, while allowing retry after failure.

Two rapid submit events produce one fetch call and one stable idempotency key.

• Guard synchronously.
• Disable the submit button.
• Reset the guard in finally.
• Use a server-supported idempotency key for consequential writes.

A ref closes the gap before the pending render, while state communicates progress. I also keep one attempt object containing the normalized command and idempotency key. A definitive rejection clears that attempt so corrected input can start a new operation; an ambiguous transport failure retains it, so Retry sends the same payload with the same key instead of risking a duplicate order.

type Attempt = {
  key: string;
  command: CreateOrderInput;
};

const submittingRef = useRef(false);
const attemptRef = useRef<Attempt | null>(null);
const [pending, setPending] = useState(false);
const [error, setError] = useState<string | null>(null);

async function submit(event: FormEvent) {
  event.preventDefault();
  if (submittingRef.current) return;

  submittingRef.current = true;
  setPending(true);
  setError(null);

  const attempt = attemptRef.current ?? {
    key: crypto.randomUUID(),
    command: normalizeOrder(values),
  };
  attemptRef.current = attempt;

  try {
    await api.createOrder(attempt.command, {
      idempotencyKey: attempt.key,
    });
    attemptRef.current = null;
  } catch (caught) {
    if (isDefinitiveRejection(caught)) {
      attemptRef.current = null;
      setError("Review the order details and try again.");
    } else {
      setError("The result is uncertain. Retry to check the same order.");
    }
  } finally {
    submittingRef.current = false;
    setPending(false);
  }
}

return <>
  <button type="submit" disabled={pending} aria-busy={pending}>
    {pending ? "Creating order" : "Create order"}
  </button>
  {error ? <p role="alert">{error}</p> : null}
</>;

isDefinitiveRejection should be based on the API client's typed outcome, not on guessing from a generic exception. While an outcome is uncertain, Retry reuses the captured command and key; changing it should be an explicit new operation after reconciliation.

The client guard improves UX; database-backed idempotency provides correctness if the browser retries after an uncertain response.

• The request fails immediately.
• The component unmounts.
• A browser/network retry occurs.
• The user retries intentionally.

• Dispatch two submits in one act block and assert one request.
• Reject definitively, correct the input, and assert the retry gets a new key.
• Simulate an ambiguous transport failure and assert Retry uses the same payload and key.
• Resolve the retry successfully and assert the next logical order gets a new key.

• Relying only on disabled rendering.
• Never clearing pending after error.
• Generating a new key during transport retry.
• Claiming UI state guarantees server uniqueness.