React 19 calls any async function run inside startTransition an Action. For a mutation with no form involved — a Delete button that calls an API and then updates state — what does running it as an Action buy you over an async onClick handler that manages its own isLoading state?

## Actions are not a form feature The word *Action* in React 19 does not mean "form submission". It means an async function whose lifetime React is tracking, and there are two ways to create one: pass it to a `<form>`'s `action` prop, or call it inside `startTransition`. The second route is how mutations that have no form — a Delete button, a Like toggle, a drag-and-drop reorder — join the same model. ```jsx const [isPending, startTransition] = useTransition(); function handleDelete(id) { startTransition(async () => { await deleteItem(id); setItems(items => items.filter(i => i.id !== id)); }); } ``` The important change from React 18 is that `startTransition` now understands the `async` function. React keeps the transition pending until the returned promise settles, so `isPending` spans the network call *and* the state update that follows it. ## What the hand-rolled version actually costs The manual equivalent looks short: ```jsx const [isLoading, setIsLoading] = useState(false); async function handleDelete(id) { setIsLoading(true); await deleteItem(id); setItems(items => items.filter(i => i.id !== id)); setIsLoading(false); } ``` And it is wrong in ways that are only visible in production: - **The flag gets stuck.** If `deleteItem` rejects, the last line never runs and the button spins forever. The fix is a `try/finally`, which every such handler must repeat. - **The failure is silent.** An unhandled rejection in a plain event handler does not reach an error boundary — it becomes an unhandled promise rejection in the console. React routing the Action gives that rejection a defined destination. - **The post-await update is urgent.** State set after an `await` in a plain handler is an ordinary update. If it renders an expensive subtree, it blocks. Inside a transition it is non-urgent work React can interleave with user input. - **Nothing else can see it.** `isLoading` is local; a spinner in an unrelated part of the tree needs it as a prop or in context. ## Non-urgent is a real behavioural difference Marking the update as a transition is not merely a scheduling hint. Two visible consequences: 1. React can keep the page responsive while the transition's render happens, because it is allowed to interrupt that render for a more urgent update such as a keystroke. 2. If the transition's update causes a component to suspend, React will not replace already-visible content with the nearest Suspense fallback; it keeps showing the previous UI until the new one is ready. For a mutation that reveals fresh data, this is the difference between a smooth swap and a flash of skeleton. ## Where the boundaries are An Action is not a request manager. React does not deduplicate concurrent Actions, does not cancel an in-flight one when a second starts, does not retry, and does not cache. If a user clicks Delete three times you get three requests, and if two Actions finish out of order the later-resolving one wins. Guarding against that — disabling the control while `isPending`, or keying results — is still yours to design, and a data library on top may be the right answer for a mutation-heavy app. A second boundary: `isPending` belongs to the `useTransition` call that started it. Two independent mutations in one component tracked through the same hook share one pending flag, which is fine for a single control and wrong for a table where each row has its own Delete. ## The interview answer in one line The reason to use an Action is not that it is shorter — it is barely shorter. It is that pending state, error routing, update priority, and optimistic-value lifetime all become properties React derives from one fact it now knows: exactly when your async work starts and stops.