React 19 useActionState Showed Me Why Disabling My Submit Button Was Never Enough

Every form shipped prior to React 19 required wiring up the exact same three pieces of state by hand every single time: one for the result, one for submission status, and one for errors. At least once a sprint, forgetting to reset one of them meant spending precious minutes staring at a frozen button. This legacy pattern sat inside dozens of components, hiding underlying flaws in how state was managed.

It wasn't until sitting down with useActionState that the realization struck: the workaround previously shipped to fix double submits wasn't actually fixing anything. Migrating forms by adding basic guards felt like just another hook to memorize at first, but it quickly transformed into the feeling that React had watched developers struggle with this pattern for years and finally built the right fix.

Stock photo for illustration only, not from the actual event

The core API structure involves:

• Passing a function and an initial state to the hook
• React calling that function with (previousState, formData) upon submission
• Whatever is returned automatically becomes the new state
• isPending being tied directly to React's native transition tracking

An initial assumption might be that rapid clicks would trigger race conditions where the last or first click wins. However, React queues every call to the action function and runs them sequentially, waiting for the previous promise to resolve before starting the next. Clicking Add to Cart four times rapidly results in taking four times as long to settle because each call patiently waits in line, ensuring nothing gets silently dropped or raced.

Source: Dev.to