Lifecycle & Actions

onFlush

Schedules callback to run once, right after the pending flush finishes, in the same microtask checkpoint (before the browser paints). Unlike onSettled, it never waits on async work: if that flush is held by a pending transition, the callback still runs.

Its main use is keeping a write out of another update's hold. Writes made in the same synchronous frame are applied together, so when one of them starts async work (a route change, a fetch), the others are held with it until it resolves. A write made in onFlush happens after that flush, so it is its own update: it commits on its own unless something it changes also derives from the held work (a memo or createEffect reading both), in which case it joins that hold as any later write would.

Call it from event handlers and effect callbacks (including createTrackedEffect and onSettled bodies). In an owned scope such as a component body or a computation it warns in dev: use onSettled there.

  • A write in the callback lands after any write made inline in the same frame. Don't write the same signal both inside and outside it; use a functional setter if the order matters.
  • Several onFlush callbacks run in call order and batch into one flush.
  • queueMicrotask is not a substitute: called before the frame's first write, it runs before that flush and its write joins it.

Import

import { onFlush } from "solid-js";

Type signature

function onFlush(callback: () => void): void;

Parameters

callback

  • Type: () => void

Function to run once after the pending flush


Examples

// A menu closes now even when the consumer's onSelect starts async work.
const select = (id: string) => {
onFlush(() => setOpen(false));
props.onSelect?.(id);
};

Learn more

Last updated: 10/28/26, 2:39 AMEdit this pageReport an issue with this page