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 callseffect.schedule(). -
EffectInstance.schedule()still callsscheduleJob(this). -
computedremains 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:
startTransitiondoes not change the priority ofsignal.set().
It only affects React’s ownsetState.
For merging multi-step data updates, usetransaction(async).
For UI transitions, useuseDeferredValueor 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, usetransaction(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
awaitboundary 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 existingbatch(). -
flushJobs()only runs when the outermost transaction exits. -
computedremains 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.