React exports startTransition as a standalone function as well as returning one from useTransition(). What is different about the standalone version, and when would you use it?
answer
- same marking, different observability
- no flag, because no component instance
- a plain import, so hook rules do not apply
- for code outside the render tree
- returns nothing at all
basics
~20 sThe standalone startTransition marks updates non-urgent exactly like the one from useTransition, but gives you no isPending flag. Because it is a plain import rather than a hook, it can be called outside components — in module-level code, store logic, or event callbacks where hooks are illegal.
solid answer
~50 sBoth mark updates the same way: `import { startTransition } from 'react'` gives you a plain function that labels every state update triggered synchronously inside its callback as non-urgent, exactly as the second item of `useTransition()` does. The difference is the pending state. The hook maintains `isPending` and re-renders your component when it changes; the standalone export has no such value, so if you need a pending indicator you must get it from a `useTransition` call somewhere. In exchange, the standalone function is not a hook and therefore is not bound by the Rules of Hooks — you can call it from module scope, from inside a store or subscription callback, or from a plain utility function that has no component to live in. That is its real use: marking updates from code that sits outside the React render tree.
go deeper
Know that both mark updates as non-urgent in the same way, and that only the hook form gives you an isPending boolean. The standalone one is a plain import from react.
Explain why the flag cannot exist on the standalone version — it is component state with no component to attach to — and note that being a plain function frees it from the Rules of Hooks.
Identify the real use case: updates originating outside the render tree, such as a socket handler or store callback, where no hook may be called but the resulting render should still yield to user input.
Decide the codebase convention: pending affordances belong to the component that renders them, so transitions started from shared infrastructure should stay flagless rather than growing an ad-hoc global pending state.
## Two ways to get the same marker ```js import { startTransition, useTransition } from 'react'; // A: standalone startTransition(() => setTab('posts')); // B: from the hook const [isPending, startTransition] = useTransition(); startTransition(() => setTab('posts')); ``` The marking behaviour is identical. In both cases the callback runs immediately and synchronously, and every state update triggered while it runs is labelled a Transition — non-urgent work React may pause in favour of an urgent update, and may restart if a newer update supersedes it. ## What the standalone version gives up It returns nothing and tracks nothing. There is no `isPending`, and there is no way to ask React whether a transition started this way is still in flight. React's own documentation calls this out as the reason to prefer the hook when you need to show pending UI. This is not merely a convenience gap. `isPending` is component state: the hook re-renders the component that reads it when the flag flips. A plain function import has no component instance to attach that to, so the capability cannot exist there. ## What it gains: no Rules of Hooks `useTransition` is a hook, so it can only be called at the top level of a component or another hook. `startTransition` is an ordinary function export, subject to none of that. It can be called: - from a module-level helper or a utility function shared across components; - inside a store's subscribe callback, a WebSocket message handler, or an event-emitter listener; - from a conditional branch, a loop, or an early return — placement is irrelevant. ```js // module scope, no component in sight socket.on('feed', payload => { startTransition(() => store.setFeed(payload)); }); ``` That is the situation the standalone export exists for: code outside the render tree that nonetheless causes a state update you would rather not have block user interaction. ## The caveat both share Only updates triggered *during* the synchronous scope are marked. Scheduling the update in a timer, or performing it after an `await`, puts it outside the scope, and it reverts to urgent: ```js startTransition(() => { setTimeout(() => setTab('posts'), 0); // urgent — the scope already returned }); ``` If you need to update after asynchronous work, wrap that later update in its own `startTransition` call at the point where it actually happens. ## Choosing between them Use the hook when the component that starts the transition also shows the feedback — dimming a panel, disabling a button, fading a stale list. Use the standalone function when there is no component in scope, or when you genuinely do not want a pending affordance and would rather avoid the extra re-render the flag causes. Mixing them is fine: one component may hold a `useTransition` for its own interactions while a shared utility uses the standalone import for background updates. ## Frequent mistakes The most common is expecting the standalone function to return something — a promise, a handle, a boolean. It returns `undefined`, and awaiting it is meaningless. The second is assuming the two versions have different priority semantics, as if the hook's transitions were somehow "stronger"; they are the same marking, and the only difference is whether a pending flag exists to observe it.
- Can you call the standalone startTransition from module scope or inside a loop?Yes — it is an ordinary function export, not a hook, so the top-level-only and React-function-only rules do not apply to it. It can be called conditionally, in a loop, from a utility module, or from a subscription callback. Only `useTransition` itself, being a hook, is bound by those placement rules.
- If a background update marked with the standalone startTransition needs a pending indicator, what do you do?Get the flag from a `useTransition` call in the component that will render the indicator, and start the transition from there instead — the flag is component state and must originate where it is rendered. If the trigger genuinely lives outside React, track that pending condition in your own state and update it explicitly.
- Does the standalone startTransition return a promise you can await?No. It returns `undefined`; awaiting it is a no-op and tells you nothing about when the resulting render commits. Marking an update as non-urgent is not a scheduling handle. If you need to know that the work finished, render from the resulting state or use the hook's `isPending` to observe the transition.
saying these in an interview costs you the question
- Thinks the standalone version has lower priority than the hook's
- Expects the standalone call to return a promise or handle
- Says the standalone function still obeys the Rules of Hooks
- Assumes isPending can be read globally without the hook
- Believes only one of the two actually marks the update