Async Transactions for Signals: Batching Updates Across await

Introduction

In the previous articles, we demonstrated how to integrate our signal mechanism into two mainstream frameworks: React and Vue.

Starting from this article, we will return to the core signal kernel we designed and examine which parts can be improved further.

Quick Overview

The goal is to merge “multi-step updates across await boundaries” into a single effect rerun, while keeping our existing lazy computed behavior and microtask-based scheduling model intact.

In this article, we only extend scheduler.ts and a few minimal integration points, without changing the public API.

Why Do We Need Async Transactions?

Our current system is already stable:

Within the same call stack, multiple set() calls are merged by our scheduler — using Set + queueMicrotask — into the same microtask, so the effect only reruns once.

But this does not work across await.

Each await creates a new microtask. Without a transaction, effects will run once per async boundary.

Without vs. With Transaction

// ❌ Without transaction: the effect runs twice
async function onClick() {
  a.set(1); // schedules the first flush
  await fetch("/api");
  b.set(2); // schedules the second flush
}

// ✅ With transaction: the effect runs once after the transaction completes
async function onClick() {
  await transaction(async () => {
    a.set(1);
    await fetch("/api");
    b.set(2);
  });
}

Minimal Change: Extending scheduler.ts

Core Idea

Reuse the existing batchDepth, so batch() and transaction() can be nested freely.

When batchDepth > 0, scheduleJob() only adds the job to the queue and does not schedule a microtask.

When the outermost transaction exits, we call flushJobs() once.

// scheduler.ts
export interface Schedulable { run(): void; disposed?: boolean }

const queue = new Set<Schedulable>();
let scheduled = false;
let batchDepth = 0;

export function scheduleJob(job: Schedulable) {
  if (job.disposed) return;
  queue.add(job);

  // Only schedule a microtask when we are not inside a batch/transaction
  if (!scheduled && batchDepth === 0) {
    scheduled = true;
    queueMicrotask(flushJobs);
  }
}

// Same as before: merge synchronous updates and flush once at the end
export function batch<T>(fn: () => T): T {
  batchDepth++;
  try {
    return fn();
  } finally {
    batchDepth--;
    if (batchDepth === 0) flushJobs();
  }
}

// Promise-like check
function isPromiseLike<T = unknown>(v: any): v is PromiseLike<T> {
  return v != null && typeof v.then === "function";
}

// New: async transaction support.
// Updates across await boundaries are merged and flushed once
// when the outermost transaction completes.
export function transaction<T>(fn: () => T): T;
export function transaction<T>(fn: () => Promise<T>): Promise<T>;
export function transaction<T>(fn: () => T | Promise<T>): T | Promise<T> {
  batchDepth++;

  try {
    const out = fn();

    if (isPromiseLike<T>(out)) {
      // Async case: wait until fn completes, then exit and flush if needed
      return Promise.resolve(out).finally(() => {
        batchDepth--;
        if (batchDepth === 0) flushJobs();
      });
    }

    // Sync case: exit immediately and flush if needed
    batchDepth--;
    if (batchDepth === 0) flushJobs();

    return out as T;
  } catch (e) {
    // Even when an exception is thrown, we must exit correctly and flush once
    batchDepth--;
    if (batchDepth === 0) flushJobs();
    throw e;
  }
}

export function flushSync() {
  if (!scheduled && queue.size === 0) return;
  flushJobs();
}

function flushJobs() {
  scheduled = false;

  let guard = 0;

  while (queue.size) {
    const list = Array.from(queue);
    queue.clear();

    for (const job of list) job.run();

    if (++guard > 10000) {
      throw new Error("Infinite update loop");
    }
  }
}

This is backward-compatible.

All existing batch() usage remains unchanged. After adding transaction(async), multiple set() calls across await boundaries can also be merged into a single effect rerun.

Existing code does not need to change:

• signal.set() still calls effect.schedule().
• EffectInstance.schedule() still calls scheduleJob(this).
• computed remains lazy: it is only marked as stale and does not enter the scheduler.

Behavioral Guarantees

computed Is Still Lazy

set() only marks the computed node as stale.

It will not be recomputed early just because it is inside a transaction.

Effects Run Once After the Transaction Ends

Any set() inside the transaction does not schedule a microtask immediately.

Only when the outermost transaction exits do we call flushJobs() once.

Nesting Is Supported

Because batchDepth is shared, nested batch() and transaction() calls work naturally.

Only the outermost exit triggers the flush.

Exception-Safe

Even if fn throws, the scheduler exits the transaction state correctly and flushes once.

See the catch / finally logic above.

Usage Guide

Using It in React

Multi-Step Updates Across await

// Counter.tsx
import React from "react";
import { signal } from "../core/signal.js";
import { createEffect } from "../core/effect.js";
import { transaction } from "../core/scheduler.js";
import { useSignalValue } from "./react-adapter";

// Data layer, independent of React
const a = signal(0);
const b = signal(0);

// Observe effect reruns
createEffect(() => {
  // A single rerun sees the latest values of both a and b
  console.log("effect run:", a.get(), b.get());
});

export function Counter() {
  const va = useSignalValue(a);
  const vb = useSignalValue(b);

  const onClick = async () => {
    await transaction(async () => {
      a.set(va + 1);
      await Promise.resolve(); // Simulate an await, such as fetch()
      b.set(vb + 1);
    }); // Flush only after the transaction ends
  };

  return (
    <div>
      <p>a={va} / b={vb}</p>
      <button onClick={onClick}>
        +a, then await, then +b (one rerun)
      </button>
    </div>
  );
}

Local Draft + Commit Once on Submit

Usually, this does not require startTransition.

import { useEffect } from "react";
import { signal } from "../core/signal.js";
import { transaction } from "../core/scheduler.js";
import { useSignalValue, useSignalState } from "./react-adapter";

const titleSig = signal("Hello");

export function Editor() {
  const committed = useSignalValue(titleSig);
  const [draft, setDraft] = useSignalState(committed); // Local signal draft

  // Optional: sync the draft when the external value changes
  useEffect(() => setDraft(committed), [committed]);

  const save = async () => {
    await transaction(() => {
      titleSig.set(draft); // Commit back to the global signal once

      // If there are many React setState calls here,
      // then consider wrapping those setState calls with startTransition.
    });
  };

  return (
    <>
      <input value={draft} onChange={(e) => setDraft(e.target.value)} />
      <button onClick={save}>Save</button>
      <p>committed: {committed}</p>
    </>
  );
}

Reminder:
startTransition does not change the priority of signal.set().
It only affects React’s own setState.
For merging multi-step data updates, use transaction(async).
For UI transitions, use useDeferredValue or local draft state/signals.

Using It in Vue

Multi-Step Updates Across await in an SFC

<script setup lang="ts">
import { signal } from "../core/signal.js";
import { transaction } from "../core/scheduler.js";
import { useSignalRef } from "./vue-adapter";

const a = signal(0);
const b = signal(0);

const va = useSignalRef(a); // Vue ref
const vb = useSignalRef(b);

async function run() {
  await transaction(async () => {
    a.set(va.value + 1);
    await Promise.resolve(); // Simulate await
    b.set(vb.value + 1);
  }); // One flush, one rerun
}
</script>

<template>
  <p>a={{ va }} / b={{ vb }}</p>
  <button @click="run">+a, await, +b (one rerun)</button>
</template>

Local Draft + Commit Once on Submit

<script setup lang="ts">
import { ref, watch } from "vue";
import { signal } from "../core/signal.js";
import { transaction } from "../core/scheduler.js";
import { useSignalRef } from "./vue-adapter";

const titleSig = signal("Hello");

const committed = useSignalRef(titleSig); // Read external value
const draft = ref(committed.value); // Local Vue state draft

// Optional: sync the draft when the external value changes
watch(committed, v => (draft.value = v));

async function save() {
  await transaction(() => {
    titleSig.set(draft.value); // Commit back once
  });
}
</script>

<template>
  <input v-model="draft" />
  <button @click="save">Save</button>
  <p>committed: {{ committed }}</p>
</template>

Reminder:
Vue’s <Transition> and animations only affect display timing.
They do not delay data writes.
For merging data commits, use transaction(async).
If you want heavy UI regions to update later, handle that at the UI layer with delayed rendering or separated display regions.

Conceptual Summary

Data Layer

Wrap multi-step writes across await boundaries in transaction(async).

Result: one effect rerun.

UI Layer

Transitions and animations control presentation timing.

Do not expect them to change when signal.set() happens.

Draft Pattern

During editing, use component-local state or local signals.

When submitting, enter a transaction and commit back to the global signal once.

Understanding the Timeline Across await

The key idea is:

• Without a transaction, every await boundary gives the scheduler a chance to flush.

• With a transaction, scheduled effects are held until the outermost transaction completes.

• That means the effect sees the final consistent state instead of intermediate states.

Conclusion

In this article, we turned “multi-step updates across await boundaries” into a single side-effect rerun.

• transaction(async) shares the same depth counter as the existing batch().
• flushJobs() only runs when the outermost transaction exits.
• computed remains lazy: it is only marked stale and never recomputed early.
• Nested and exceptional cases are handled safely.
• The current API and mental model remain intact.

In the next article, we will upgrade “merging” into “atomicity”.

If something fails, the state should roll back to what it was before entering the transaction.

In short:

This article solves the “run once” problem.

The next article solves the “all or nothing” problem.