The Rendering Opportunity

• Click dispatched (task begins) — The handler starts. From here until it returns, no frame is possible.
• setLoading(true) → DOM marked dirty — The document is invalidated. Nothing is painted; nothing can be.
• Heavy synchronous work — The spinner exists in the DOM for this entire span and is never on screen.
• Microtask checkpoint — Still no frame. This phase is before rendering, not after it.
• Paint + composite — The first frame the user sees — and it already shows the finished result.

The two DOM writes are net-zero by the time a frame exists. Splitting the task in two — write, return, then start the work — is the whole fix.

1. 1
   Resize and scroll steps

   Fire the resize and scroll events that the browser has been coalescing since the last frame.

   fails by A non-passive scroll handler doing work here delays the frame it is part of (Passive Listeners).

2. 2
   Animation-frame callbacks

   Run every requestAnimationFrame callback registered before this frame, in registration order, each followed by a microtask checkpoint.

   fails by Long callbacks push the frame late; a callback registering another runs next frame, not this one.

3. 3
   ResizeObserver deliveries

   Deliver size-change records, potentially triggering another layout pass within the same frame.

   fails by An observer that resizes what it observes; the browser bounds the loop and reports undelivered notifications.

4. 4
   IntersectionObserver deliveries

   Deliver visibility-change records for observed elements.

   fails by Heavy work in a delivery — a common lazy-loading mistake — spends frame time on things that are not yet visible (Lazy Loading).

5. 5
   Style, layout, paint, composite

   Recompute what was invalidated and produce the frame.

   fails by A change that invalidates layout for the whole document instead of one subtree (CSS Containment).

Everything above happens after the microtask checkpoint and before the next task. There is no author-facing hook after paint in this sequence.

button.addEventListener("click", async () => {
  setPending(true);            // DOM dirty, nothing painted
  await computeReport(rows);   // resolves from memory -> microtask
  setPending(false);           // still the same task
});
// The user sees: nothing, then the finished report.

button.addEventListener("click", () => {
  setPending(true);
  // end this task; let the browser reach its rendering phase
  requestAnimationFrame(() => setTimeout(() => {
    const report = computeReport(rows);
    setPending(false);
    show(report);
  }));
});
// The user sees: pending state, then the finished report.

The rendering opportunity only exists between tasks, so the only way to guarantee the pending state is painted is to return from the handler before starting the work. Nesting a timer inside an animation-frame callback is the blunt, portable way to say "after the next frame has actually been produced" — a scheduler API expresses the same intent more directly where it is available (Yielding and Scheduling).