startTransition runs your callback immediately and only demotes the set calls inside it

Filtering a long list as someone types has no side effect to run and no single result to track, and the dev.to guide says useActionState was never built for it ^[19]. So the search example uses two pieces of state doing two different jobs. `query` is set outside the Transition. The controlled input updates on the keystroke, and typing never lags ^[15]. `filterQuery` is set inside it, and the guide says it "lags behind" query on purpose ^[15]. `filtered` is a plain expression recomputed on every render from `filterQuery`, and not state at all ^[16].

What the Transition buys is narrower than the wrapper suggests. `products.filter()` still runs as ordinary, uninterrupted JavaScript, exactly as it would outside a Transition ^[17]. React decides whether the render containing that iteration can be cut in front of by a more urgent update, which here is the next keystroke ^[17]. The iteration itself is not chunked. One pass over a big array takes as long as it took before; the render it feeds can now be abandoned and restarted ^[17].

The contract stops at two values, `isPending` then `startTransition`, always in that order ^[9]. The function returns nothing, so whatever your callback returns is discarded unless you store it yourself ^[13]. The hook has no built-in error state and no queue ^[13]. useActionState is the hook that hands back your function's return value as state ^[14]. A handler that needs the server's answer, or a message on failure, needs code this hook does not supply. The guide calls useTransition "the easiest one to get partially right" ^[5] and names where that surfaces: a fast double-click, a function that throws, a text input ^[6].

Nothing about `startTransition` is delayed or scheduled for later, despite the name ^[11]. The callback runs right away and synchronously, and what changes priority is any `set` call that happens while it is running ^[11][12]. `isPending` then covers the whole span. It is true at the first `startTransition` call and stays true until every Action in that Transition, including anything you awaited, has completed and the resulting state is shown ^[10]. In the example that one flag dims the list to 0.6 opacity while stale results are still on screen ^[18].

Claims about a scheduler need a version attached. The guide tested its examples against React 19.2.8, and re-ran the race condition, error boundary and overlapping-Transition checks on 19.3.0, which shipped on September 9 ^[7][8]. Those two builds are the only React versions it names ^[21]. On an earlier 19.x release these are claims about someone else's build, and the guide's later sections, covering the race-condition and error-boundary results, were not available ^[22].

In my view the two-variable split is the right default anywhere a rendered list derives from an input, because the cost is one extra `useState` and one opacity rule ^[15][16][18]. I would not reach for it on a submit handler that has a result to report. Three of the four hooks in this series need something else driving ^[20]. useTransition is the one that drives alone, and it is also the one with the least structure underneath it ^[1].