flush

Synchronously processes the pending reactive queue, or runs fn in a synchronous flush scope before draining the queue.

Reactive updates are normally batched onto the microtask queue, so multiple writes in a row collapse into a single update pass. Call flush() when you need to observe the result of those writes synchronously — most commonly in tests, but also at the boundary of imperative integration code. Pass a callback when the writes themselves should bypass microtask scheduling and drain synchronously when the callback returns.

Import

import { flush } from "solid-js";

Type signature

function flush(): void;
function flush<T>(fn: () => T): T;

Parameters

fn

• Type: () => T

Optional callback whose writes bypass microtask scheduling; the queue drains when it returns.

Return value

The value returned by fn, when one was passed.

Examples

const [count, setCount] = createSignal(0);
const doubled = createMemo(() => count() * 2);

setCount(5);
flush();
expect(doubled()).toBe(10);

flush(() => setCount(6));
expect(doubled()).toBe(12);

// Nested flushes drain at each level:
flush(() => {
  setCount(7);
  flush(() => setCount(8)); // inner drain — effects fire here
  // outer continues with up-to-date state
});

Caveats

• Do not call flush() inside an action body or an onSettled callback; the queue is already draining there. Defer it with queueMicrotask if needed.
• Flushing does not resolve async work. A memo waiting on a promise stays pending after flush().

Common problems

• The test sees the old DOM
• Reading a signal right after setting it gives the old value

Learn more

• When updates land
• Testing
• Reactivity
• Async reactivity
• Debugging reactivity