Forem: Luciano0322

I published a new article on atomic transactions for signals. The core idea: all succeed, or nothing changes. I also covered rollback, nested transactions, and React/Vue examples.

Luciano0322 — Mon, 04 May 2026 05:48:49 +0000

Luciano0322

May 4

Building Atomic Transactions with Rollback for Signals

#webdev #javascript #frontend #typescript

Comments

8 min read

Building Atomic Transactions with Rollback for Signals

Luciano0322 — Mon, 04 May 2026 05:45:29 +0000

What Is an Atomic Transaction?

Before we begin, let’s define atomic transaction clearly:

“It is a protective wrapper around multiple state updates that guarantees the whole operation either succeeds completely or has no effect at all.”

Inside an atomic transaction, you can perform multiple set() calls, and even cross multiple await boundaries. Only when the entire operation succeeds do we commit everything at once and rerun effects with a single flush. If anything fails halfway through, all touched signals are restored to their pre-transaction values, and the error state is never pushed outward.

This is different from a regular batch / transaction, which only coalesces reruns. An atomic transaction adds rollback semantics:

“Commit everything once on success; undo everything on failure.”

At the same time, it does not change the mental model of our core runtime: computed stays lazy, and the dependency graph remains intact.

Behavior Definition

Now that the concept is clear, let’s define the behavior we want to implement:

Success

All signal.set() calls inside the transaction are committed, and when the outermost level exits, we call flushJobs() once, so our effects rerun only once.

Failure (throw / reject)

All affected signals are restored to the values they had when entering the current transaction level. We do not flush, so invalid intermediate state is never pushed into effects. Downstream computed nodes are marked as stale and will lazily recompute on the next read.

Nested transactions

Each level maintains its own write log.

If an inner transaction succeeds, its log is merged into the outer transaction, while preserving the outermost original value.
If an inner transaction fails, only the inner transaction is rolled back. The outer transaction may either catch the error and continue, or let it propagate upward.

Equality semantics

Consistent with the core runtime, Object.is(prev, next) means “no change”: no log entry, no scheduling.

API and File Structure

Add the following to scheduler.ts:

atomic(fn): atomic transaction, supports both sync and async flows
inAtomic(): whether execution is currently inside any atomic level
recordAtomicWrite(node, prev): records the previous value the first time a node is written in the current level
scheduleJob: reuse the existing batch / transaction gating logic, using batchDepth to decide whether to defer the microtask

And in signal.set(), at the exact moment when the equality check passes and we are certain the write will happen, insert:

if (inAtomic()) recordAtomicWrite(node, prev)

Extending `scheduler.ts`

import { markStale } from "./computed.js";
import type { Node } from "./graph.js";

export interface Schedulable { run(): void; disposed?: boolean }

// Internal node shape used by signal/computed
export type InternalNode<T = unknown> = { value: T };

// Write log for atomic transactions
type WriteLog = Map<(Node & InternalNode<unknown>), unknown>;

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

// > 0 means we are inside batch/transaction mode (delay microtask flushing)
let batchDepth = 0;

// Atomic transaction depth and log stack
let atomicDepth = 0;
const atomicLogs: WriteLog[] = [];

// Mute scheduling during rollback to prevent scheduleJob from creating new work
let muted = 0;

export function scheduleJob(job: Schedulable) {
  if (job.disposed) return;
  queue.add(job);
  if (!scheduled && batchDepth === 0) {
    scheduled = true;
    queueMicrotask(flushJobs);
  }
}

export function batch<T>(fn: () => T): T {
  batchDepth++;
  try {
    return fn();
  } finally {
    batchDepth--;
    if (batchDepth === 0) flushJobs();
  }
}

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

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)) {
      return Promise.resolve(out).finally(() => {
        batchDepth--;
        if (batchDepth === 0) flushJobs();
      });
    }
    batchDepth--;
    if (batchDepth === 0) flushJobs();
    return out as T;
  } catch (e) {
    batchDepth--;
    if (batchDepth === 0) flushJobs();
    throw e;
  }
}

// Atomic transaction (with rollback)
export function inAtomic() {
  return atomicDepth > 0;
}

// Record the "first write in this level"; called by signal.set() when a write is confirmed
export function recordAtomicWrite<T>(node: Node & InternalNode<T>, prevValue: T) {
  const log = atomicLogs[atomicLogs.length - 1];
  if (!log) return; // safety guard: no active atomic layer
  if (!log.has(node)) log.set(node, prevValue);
}

function writeNodeValue<T>(node: Node & InternalNode<T>, v: T) {
  if ("value" in node) (node as { value: T }).value = v;
}

function mergeChildIntoParent(child: WriteLog, parent: WriteLog) {
  for (const [node, prev] of child) {
    if (!parent.has(node)) parent.set(node, prev);
  }
}

export function atomic<T>(fn: () => T): T;
export function atomic<T>(fn: () => Promise<T>): Promise<T>;
export function atomic<T>(fn: () => T | Promise<T>): T | Promise<T> {
  // Enter atomic layer: suppress flushing (shared batchDepth), start write logging
  batchDepth++;
  atomicDepth++;
  atomicLogs.push(new Map<(Node & InternalNode<unknown>), unknown>());

  const exitCommit = () => {
    const log = atomicLogs.pop()!;
    atomicDepth--;
    // Inner success -> merge first-seen old values into parent
    if (atomicDepth > 0) {
      mergeChildIntoParent(log, atomicLogs[atomicLogs.length - 1]!);
    }
    // Only flush when the outermost layer exits
    batchDepth--;
    if (batchDepth === 0) flushJobs();
  };

  const exitRollback = () => {
    const log = atomicLogs.pop()!;
    atomicDepth--;
    // Silent rollback: avoid scheduling while restoring values
    muted++;
    try {
      for (const [node, prev] of log) {
        writeNodeValue(node, prev);
        if ((node as Node).kind === "signal") {
          for (const sub of (node as Node).subs) {
            if (sub.kind === "computed") markStale(sub);
            // sub.kind === "effect" does not need scheduling
            // muted blocks it, and we also do not flush afterward
          }
        }
      }
      queue.clear(); // clear jobs created during this level
      scheduled = false;
    } finally {
      muted--;
    }
    // No flush on failure; just exit batch/atomic depth
    batchDepth--;
  };

  try {
    const out = fn();
    if (isPromiseLike<T>(out)) {
      return Promise.resolve(out).then(
        (v) => { exitCommit(); return v; },
        (err) => { exitRollback(); throw err; }
      );
    }
    // Synchronous success
    exitCommit();
    return out as T;
  } catch (e) {
    // Synchronous failure -> rollback
    exitRollback();
    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");
  }
}

Consistency Guarantees

When an atomic transaction fails:

all affected computed nodes are marked as stale
on the next read after rollback, they lazily recompute based on the latest signal values
the UI never sees the invalid snapshot, and no flush happens during rollback

Adjustments in `signal.ts`

import { markStale } from "./computed.js";
import { link, track, unlink, type Node } from "./graph.js";
import { SymbolRegistry as Effects } from "./registry.js";
import { inAtomic, recordAtomicWrite, type InternalNode } from "./scheduler.js";

type Comparator<T> = (a: T, b: T) => boolean;
const defaultEquals = Object.is;

export function signal<T>(initial: T, equals: Comparator<T> = defaultEquals) {
  const node: Node & InternalNode<T> & { kind: "signal"; equals: Comparator<T> } = {
    kind: "signal",
    deps: new Set(),
    subs: new Set(),
    value: initial,
    equals,
  };

  const get = () => {
    track(node);
    return node.value;
  };

  const set = (next: T | ((prev: T) => T)) => {
    const prev = node.value;
    const nxtVal = typeof next === "function" ? (next as (p: T) => T)(node.value) : next;
    if (node.equals(node.value, nxtVal)) return;

    // Atomic hook: record the previous value only when the write is confirmed,
    // and only the first time this level touches the node
    if (inAtomic()) recordAtomicWrite(node, prev);

    // Perform the actual write
    node.value = nxtVal;

    // No downstream subscribers -> exit early to avoid unnecessary work
    if (node.subs.size === 0) return;

    // Has downstream subscribers -> follow the original propagation logic
    for (const sub of node.subs) {
      if (sub.kind === "effect") {
        Effects.get(sub)?.schedule();
      } else if (sub.kind === "computed") {
        markStale(sub);
      }
    }
  };

  const subscribe = (observer: Node) => {
    if (observer.kind === "signal") {
      throw new Error("A signal cannot subscribe to another node");
    }
    link(observer, node);
    return () => unlink(observer, node);
  };

  return { get, set, subscribe, peek: () => node.value };
}

Usage Scenarios

Inner transaction fails, outer transaction continues

(only the inner level rolls back)

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

await atomic(async () => { // outer
  a.set(1); // OK
  try {
    await atomic(async () => { // inner
      b.set(1);
      throw new Error("boom"); // inner fails -> rollback b to 0
    });
  } catch {}
  // At this point: a = 1, b = 0
}); // outer succeeds -> one flush

Outer transaction fails

(everything rolls back)

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

try {
  await atomic(async () => {
    a.set(1);
    await Promise.resolve();
    b.set(2);
    throw new Error("oops"); // entire transaction fails -> rollback both a and b
  });
} catch {}

// a = 0, b = 0
// and there was no flush in this transaction

React / Vue Examples

Using Atomic Transactions with Rollback in React

Scenario: editing a title. When the user clicks Save, we use atomic for an optimistic write. Only a successful request commits the update; failure rolls everything back.

import { useState, useEffect } from "react";
import { signal } from "../core/signal.js";
import { atomic } from "../core/scheduler.js";
import {
  useSignalValue,
  useSignalState,
  useComputed,
} from "../hook/react_adapter.js";

// ---- mock API ----
async function postTitle(v: string, shouldFail = false) {
  await new Promise((r) => setTimeout(r, 300)); // simulate latency
  if (shouldFail) throw new Error("server says no");
  return true;
}

// ---- state ----
const titleSig = signal("Hello");

// for unit test
export type EditorTestProps = { __sig?: ReturnType<typeof signal<string>> };

export function Editor({ __sig }: EditorTestProps = {}) {
  const sig = __sig ?? titleSig; // default: module-scope signal; tests can override it

  const committed = useSignalValue(sig); // read snapshot from external signal
  const [draft, setDraft] = useSignalState(committed); // local draft state
  useEffect(() => setDraft(committed), [committed]);

  const len = useComputed(() => titleSig.get().length); // ✅ hook returns a value

  const [saving, setSaving] = useState(false);
  const [error, setError] = useState<string | null>(null);
  const [shouldFail, setShouldFail] = useState(false);

  const save = async () => {
    setSaving(true);
    setError(null);
    try {
      await atomic(async () => {
        sig.set(draft); // optimistic write (does not flush immediately)
        await postTitle(draft, shouldFail); // may throw -> rollback + no flush
      });
      // Success: only flush when atomic exits, so committed/len update together
    } catch (e: any) {
      setError(e?.message ?? "save failed");
    } finally {
      setSaving(false);
    }
  };

  return (
    <section>
      <input
        value={draft}
        onChange={(e) => setDraft(e.target.value)}
        disabled={saving}
      />
      <button onClick={save} disabled={saving}>
        {saving ? "Saving..." : "Save"}
      </button>
      <label style={{ marginLeft: 8 }}>
        <input
          type="checkbox"
          checked={shouldFail}
          onChange={(e) => setShouldFail(e.target.checked)}
        />
        simulate failure
      </label>

      <hr />
      <p>
        Committed title: <b>{committed}</b>
      </p>
      <p>
        Derived length (computed): <b>{len}</b>
      </p>
      {error && <p style={{ color: "crimson" }}>Error: {error}</p>}
    </section>
  );
}

Success
Click Save → wait 300ms → committed and len update in the same cycle with one flush.

Failure
Click Save with simulate failure checked → the old value remains visible. The affected computed is marked as stale, and the next read (for example, after the next successful update or any later reactive access) lazily recomputes to a consistent snapshot.

Using Atomic Transactions with Rollback in Vue

Same scenario, but as an SFC. We bridge into Vue using useSignalRef / useComputedRef.

<script setup lang="ts">
import { ref, watch } from "vue";
import { signal } from "../core/signal.js";
import { atomic } from "../core/scheduler.js";
import { useSignalRef, useComputedRef } from "../hook/vue_adapter.js";

// ---- mock API ----
async function postTitle(v: string, shouldFail = false) {
  await new Promise((r) => setTimeout(r, 300));
  if (shouldFail) throw new Error("server says no");
  return true;
}

// ---- state ----
const titleSig = signal("Hello");
const committed = useSignalRef(titleSig);
const titleLen = useComputedRef(() => titleSig.get().length);

const draft = ref(committed.value);
watch(committed, (v) => (draft.value = v)); // sync draft when external value changes

const saving = ref(false);
const error = ref<string | null>(null);
const shouldFail = ref(false);

async function save() {
  saving.value = true;
  error.value = null;
  try {
    await atomic(async () => {
      // optimistic write, but no immediate flush
      titleSig.set(draft.value);
      await postTitle(draft.value, shouldFail.value); // may throw
    });
    // Success: only flush after atomic exits -> one template update
  } catch (e: any) {
    // Failure: rollback, no flush -> template keeps showing the old value
    error.value = e?.message ?? "save failed";
  } finally {
    saving.value = false;
  }
}
</script>

<template>
  <section>
    <div>
      <label>
        Draft:
        <input v-model="draft" :disabled="saving" />
      </label>
      <button @click="save" :disabled="saving">
        {{ saving ? "Saving..." : "Save" }}
      </button>
      <label style="margin-left: 8px">
        <input type="checkbox" v-model="shouldFail" :disabled="saving" />
        simulate failure
      </label>
    </div>

    <hr />

    <p>
      Committed title: <b>{{ committed }}</b>
    </p>
    <p>
      Derived length (computed): <b>{{ titleLen }}</b>
    </p>
    <p v-if="error" style="color: crimson">Error: {{ error }}</p>
  </section>
</template>

Success
After clicking Save, committed and titleLen update together in the same patch cycle.

Failure
The UI keeps showing the previous value. Because rollback already marked the affected computed nodes as stale, any future read will lazily recompute them back to the correct state.

Execution Timeline (Success vs Failure)

Closing Thoughts

With atomic, our state update model becomes more complete. Even when async work fails, the system can preserve the previous stable state, fully delivering on the original idea:

“It is a protective wrapper around multiple state updates that guarantees the whole operation either succeeds completely or has no effect at all.”

In the next article, we’ll move on to more advanced topics around the Scheduler.

New article in my signal-kernel series: Async Transactions for Signals How do you batch updates across await boundaries without breaking lazy computed or your scheduler model? This article shows the implementation and the trade-offs.

Luciano0322 — Mon, 27 Apr 2026 00:44:09 +0000

Luciano0322

Apr 27

Async Transactions for Signals: Batching Updates Across await

#webdev #javascript #frontend #signal

Comments

6 min read

Async Transactions for Signals: Batching Updates Across await

Luciano0322 — Mon, 27 Apr 2026 00:39:00 +0000

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.

Signals in Vue (II): Interop, Async Patterns, SSR, and Common Pitfalls

Luciano0322 — Mon, 20 Apr 2026 02:16:07 +0000

Quick Overview

How watch / watchEffect should be split from our createEffect
How to avoid leftover subscriptions/computed nodes during component remounts (key changes)
Two practical ways to handle async data, and how to optionally integrate with Vue Suspense
Snapshot and subscription timing for SSR / Hydration
Performance practices with equality comparison (equals) and normalized writes
Common Vue pitfalls → corrected patterns

`watch` / `watchEffect`: who should observe what?

Guiding principles

On the Vue side, only observe values (refs).

Use useSignalRef() first to bridge a signal / computed into a Vue ref, then use watch / watchEffect.
For data-layer side effects (requests, caching, logging), use our createEffect.

Do not mix Vue’s tracking system into our dependency graph.

Comparison example

Anti-pattern: calling .get() directly inside watchEffect (double tracking)

watchEffect(() => {
  console.log(priceSig.get()); // ❌ Vue is now involved in our dependency graph
});

Correct: bridge it into a Vue ref first, then watch the value

const price = useSignalRef(priceSig);

watch(price, (nv, ov) => {
  console.log("price:", ov, "→", nv);
});

Data-layer side effects should still stay in our effect system

createEffect(() => {
  const id = productIdSig.get();
  fetch(`/api/p/${id}`).then(/* ... */); // business effect
});

Remounts with `key`: lifecycle matters

This is conceptually similar to the React lifecycle scenarios discussed earlier. Vue also uses a VDOM-based mechanism, so the behavior is fundamentally the same:

when a list item or route changes its key, the old subtree is unmounted and a new subtree is mounted.

If your computed value is created at module scope and never unsubscribed, upstream dependency edges can remain alive after the old subtree is gone.

Solution A: component-scoped `useComputedRef`

Dispose automatically on unmount

const subtotal = useComputedRef(() =>
  cartSig.get().items.reduce((s, i) => s + i.qty * i.price, 0)
);
// `useComputedRef` will dispose it automatically on unmount

Solution B: containerize the lifecycle with a Provider

const StoreKey = Symbol() as InjectionKey<{ subtotal: ReturnType<typeof coreComputed> }>;

export function provideStore() {
  const subtotal = coreComputed(/* ... */);
  provide(StoreKey, { subtotal });
  onUnmounted(() => subtotal.dispose?.());
}

Async data

Approach A: state-driven rendering

Let our data-layer effect manage the lifecycle. Vue only renders the three states.

export const userId = signal(1);

export const user = signal<{
  status: "idle" | "loading" | "ok" | "error";
  data?: User;
  err?: any;
}>({ status: "idle" });

createEffect(() => {
  const id = userId.get();
  user.set({ status: "loading" });

  fetch(`/api/user/${id}`)
    .then((res) => res.json())
    .then((data) => user.set({ status: "ok", data }))
    .catch((err) => user.set({ status: "error", err }));
});

<script setup lang="ts">
const u = useSignalRef(user);
</script>

<template>
  <Spinner v-if="u.status === 'loading'" />
  <ErrorView v-else-if="u.status === 'error'" :err="u.err" />
  <Profile v-else :data="u.data" />
</template>

Approach B: Suspense resource

Wrap the three-state model into a read() API. If the value is not ready, throw a Promise and let Vue Suspense handle it.

export function toResource<T>(src: { peek(): { status: string; data?: T; err?: any } }) {
  let pending: Promise<void> | null = null;

  return {
    read(): T {
      const s = src.peek();

      if (s.status === "ok") return s.data!;
      if (s.status === "error") throw s.err;

      if (!pending) pending = new Promise(() => {});
      // Remember to replace this with a real pending promise in actual usage.
      throw pending;
    }
  };
}

<script setup lang="ts">
const resource = toResource(user);
const data = resource.read(); // throws while pending, handled by Suspense
</script>

<template>
  <Profile :data="data" />
</template>

<Suspense>
  <UserPanel />
  <template #fallback><Spinner /></template>
</Suspense>

If your project does not rely heavily on Suspense, Approach A is usually enough.
If you already have Suspense infrastructure, Approach B can fit naturally into that pattern. Just make sure you use a real pending promise, not a fake placeholder forever.

SSR / Hydration: snapshot and subscription timing

Snapshot: the initial value of useSignalRef comes from peek(), so you already have a stable value before hydration.
Subscription timing: if you want to be more conservative, you can establish the createEffect subscription only inside onMounted() to avoid starting timers or requests during SSR.

SSR-compatible example

export function useSignalRefSSR<T>(src: Readable<T>): Ref<T> {
  const r = shallowRef<T>(src.peek()) as Ref<T>;
  let stop: (() => void) | undefined;

  onMounted(() => {
    stop = createEffect(() => {
      r.value = src.get();
    });
  });

  onUnmounted(() => stop?.());
  return r;
}

The key idea is simple:

do not perform side effects during render, and start subscriptions only after mount so the SSR side does not accidentally schedule timers or network requests.

Equality strategy and performance: `equals` and normalized writes

useComputedRef(fn, equals) pushes the “skip update when values are equal” strategy down into the core signal mechanism. Vue only receives actual changes.

For arrays / objects, you can use strategies such as shallowEqual, keyedEqual, or similar custom comparisons.

const sorted = useComputedRef(
  () => [...listSig.get()].sort((a, b) => a.id - b.id),
  (a, b) => a.length === b.length && a.every((x, i) => x.id === b[i].id)
);

This means Vue only updates when the sorted result is meaningfully different.

You should also avoid unnecessary writes at the source:

userSig.set(prev => (prev.name === next ? prev : { ...prev, name: next }));

If nothing really changed, do not write.
That reduces wasted recomputation from the source of truth.

Common pitfalls and fixes

Reading `ref.value` inside `useComputedRef`

Symptom:
It becomes a purely Vue-side computation and no longer participates in our reactive graph. That means you lose lazy evaluation, caching, and our dependency tracking.

Fix:
Inside the callback, read from signal.get().
If it is meant to be a pure Vue computation, use Vue’s computed instead.

// ❌
const wrong = useComputedRef(() => vueRef.value * 2);

// ✅
const ok = useComputedRef(() => countSig.get() * 2);

Calling `.get()` directly in the template or in `setup`

Symptom:
You only get a snapshot once, and it will not update reactively.

Fix:
Expose it as a Vue ref via useSignalRef.

<!-- ❌ -->
<p>{{ countSig.get() }}</p>

<!-- ✅ -->
<p>{{ useSignalRef(countSig) }}</p>

Using `watchEffect` to read `.get()`

Symptom:
watchEffect reruns unexpectedly, lifecycle timing becomes harder to reason about, and it may even interfere with our own effect system.

Fix:
Convert the source into a Vue ref first with useSignalRef(), then use watch / watchEffect.
Or move that side effect back into our createEffect.

// ❌ Directly reading `.get()` pulls Vue tracking into our graph
watchEffect(() => {
  console.log("price:", priceSig.get());
});

// ✅ Convert to Vue ref first, then watch the value
const price = useSignalRef(priceSig);

watch(price, (nv, ov) => {
  console.log("price:", ov, "→", nv);
});

// ✅ If it is a data-layer side effect, use our effect system instead
createEffect(() => {
  const id = productIdSig.get();
  fetch(`/api/p/${id}`).then(/* ... */);
});

Module-scoped computed values that are never cleaned up

Symptom:
After route changes or key changes, the old page is gone, but some computations/subscriptions are still alive and may continue to trigger upstream updates.

Fix:
Bind derived values to the component lifecycle with useComputedRef, or manage them centrally in a Provider and dispose them explicitly.

// ❌ Module-scoped computed lives forever and may leave stale dependencies behind
export const subtotal = computed(() => a.get() + b.get());

// ✅ Component-scoped, auto-disposed on unmount
const subtotal = useComputedRef(() => aSig.get() + bSig.get());

// ✅ Containerized lifecycle management
const StoreKey = Symbol();

export function provideStore() {
  const subtotal = coreComputed(() => aSig.get() + bSig.get());
  provide(StoreKey, { subtotal });
  onUnmounted(() => subtotal.dispose?.());
}

Expecting Vue `<Transition>` / animations to delay data writes

Symptom:
You assume <Transition> delays the effect of signal.set().
In reality, the data updates immediately. Dependents react immediately too; the animation only affects how the UI is displayed.

Fix:
Keep data updates immediate in signals. Put the transition logic in the display layer, or use a local draft/copy and only commit back to the signal when needed.

<!-- ❌ Thinking Transition delays the data write -->
<script setup lang="ts">
const q = useSignalRef(querySig);

function onInput(e: Event) {
  querySig.set((e.target as HTMLInputElement).value); // still updates immediately
}
</script>

<template>
  <input :value="q" @input="onInput" />
  <Transition><Expensive :query="q" /></Transition>
</template>

Correct: delay only the displayed value

<script setup lang="ts">
import { shallowRef, watch } from "vue";

const q = useSignalRef(querySig);
const shown = shallowRef(q.value);

let t: any;

watch(q, (nv) => {
  clearTimeout(t);
  t = setTimeout(() => {
    shown.value = nv;
  }, 200);
});
</script>

<template>
  <input :value="q" @input="e => querySig.set((e.target as HTMLInputElement).value)" />
  <Transition><Expensive :query="shown" /></Transition>
</template>

Correct: use a draft and commit later

<script setup lang="ts">
import { ref, watch } from "vue";

const committed = useSignalRef(titleSig);
const draft = ref(committed.value);

watch(committed, v => {
  draft.value = v; // keep local copy in sync with external updates
});

function save() {
  titleSig.set(draft.value); // global update only on commit
}
</script>

<template>
  <input v-model="draft" />
  <button @click="save">Save</button>
</template>

Transition and animations only affect presentation, not when data is written.

If you need visual delay, delay the displayed value.
If you need commit-on-save semantics, use a local draft and write back later.

Closing thoughts

At this point, we have a one-way, predictable adapter:

signals still own dependency tracking and lazy recomputation
Vue is responsible only for rendering and UI lifecycle

I chose these two frameworks as demonstration targets. Why not keep going through more frameworks?

Because, as I mentioned in earlier articles, frontend frameworks generally handle UI in two broad styles:

Template-based Bindings and directives in HTML-like templates, such as Vue / Angular / Svelte templates
JSX-based UI expressed in JavaScript, such as React / Preact / Solid

The solutions shown here already cover those two directions. Other frameworks are usually variations of the same ideas, so I will stop here instead of repeating similar patterns.

Additional notes

Tagged template / HTML-in-JS: Lit, htm, and similar tools (not JSX, and not the same as traditional template systems)
Compiled templates: Svelte, Marko (template syntax, but compiled into imperative DOM operations instead of using a VDOM)
DOM-first / enhancement-oriented: htmx, Alpine, Stimulus (behavior attached to existing HTML, usually driven by attributes)
Resumability: Qwik (often written in JSX, but with an execution model very different from React)

In the next article, we will return to more advanced Signal topics and revisit how to further optimize the core mechanism.

Signals in Vue (I): A Minimal Bridge to the Composition API

Luciano0322 — Thu, 16 Apr 2026 00:52:07 +0000

Quick Recap

In the previous chapters, we completed the integration with the React environment.
Now let's try introducing our signals system into a Vue environment.

Goal of This Article

Safely connect our signal / computed primitives to the Vue 3 Composition API, so they can be used directly inside templates while preserving the behavior of our own reactive graph:

push dirty-marking + pull recomputation
avoiding double dependency tracking
preventing scheduler conflicts

Design Principles

One-way bridge

Only synchronize the value into a Vue ref.
Do not feed Vue's reactivity back into your graph to avoid circular scheduling.

Clear lifecycle

Clean up createEffect and (if used) computed.dispose() inside onUnmounted.

Snapshot source

Use peek() for initialization (no tracking, lazy recomputation if necessary)
Use get() inside our effect (to establish dependencies)

Consistent mental model

The callback passed to useComputedRef must read signal.get() in order to establish dependencies.

If you're doing pure Vue computation, just use Vue's computed.

Who Depends on Whom (Vue Version)

Templates and watch* only observe Vue refs (via useSignalRef)
Our computed reads signal.get() inside the callback to establish dependencies

Implementing the Adapter

import { shallowRef, onUnmounted, type Ref } from "vue";
import { createEffect, onCleanup } from "../core/effect.js";
import { computed as coreComputed } from "../core/computed.js";

type Readable<T> = { get(): T; peek(): T };

// Map signal/computed to a Vue ref
// (tear-free; driven by our effect)
export function useSignalRef<T>(src: Readable<T>): Ref<T> {
  const r = shallowRef<T>(src.peek()) as Ref<T>; // initial snapshot (no tracking)

  const stop = createEffect(() => {
    // Read inside a tracking context so updates propagate
    r.value = src.get();

    onCleanup(() => {
      // optional extension point (e.g. cancel timers)
    });
  });

  onUnmounted(() => stop()); // unsubscribe when component unmounts
  return r;
}

// Create a computed inside the component lifecycle
// and expose it as a Vue ref
export function useComputedRef<T>(
  fn: () => T,
  equals: (a: T, b: T) => boolean = Object.is
): Ref<T> {
  // Important: fn must read signal.get() to establish dependencies
  const memo = coreComputed(fn, equals);

  const r = useSignalRef<T>({
    get: () => memo.get(),
    peek: () => memo.peek()
  });

  onUnmounted(() => memo.dispose?.());

  return r;
}

Why `shallowRef`?

We already perform equality checks and caching inside the core.

Vue only needs to know whether the value changed.

Deep tracking should remain the responsibility of the core equality strategy (equals), not Vue.

Update and Cleanup Timing

Use peek() for the initial snapshot
Use get() inside the effect to establish dependencies
onUnmounted → stop() ensures no subscriptions remain

Usage Example (SFC)

Counter: signal + derived value

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

const countSig = signal(0);

const count = useSignalRef(countSig); // Vue ref
const doubled = useComputedRef(() => countSig.get() * 2); // dependency via .get()

const inc = () => countSig.set(v => v + 1);
</script>

<template>
  <p>{{ count }} / {{ doubled }}</p>
  <button @click="inc">+1</button>
</template>

Selector: observing only part of an object

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

const userSig = signal({ id: 1, name: "Ada", age: 37 });

// Only expose name
// If other fields change but name remains equal,
// the template will not re-render
const nameRef = useComputedRef(
  () => userSig.get().name,
  (a, b) => a === b
);
</script>

<template>
  <h2>{{ nameRef }}</h2>
</template>

Module-Scoped vs Component-Scoped Computed

Component scope

Use useComputedRef.
It will automatically call dispose() when the component unmounts.

Module scope

If you create a global computed, make sure to manually call dispose() when it's no longer needed.

Interoperability with `watch` / `watchEffect`

Observing your signals or computed values

First convert them to a Vue ref with useSignalRef, then observe them with watch or watchEffect.

This ensures Vue only observes the value, without participating in your dependency graph.

const price = useSignalRef(priceSig);

watch(price, (nv, ov) => {
  console.log("price changed:", ov, "→", nv);
});

Do not read signal.get() directly inside watchEffect.

That would make Vue's dependency tracking join our graph, potentially causing unnecessary reruns and lifecycle conflicts.

Responsibility Boundaries

Data / business logic

Handled by our createEffect.

UI / DOM logic

Handled by Vue lifecycle hooks (onMounted, watch, etc.).

watch should observe the Vue ref returned by useSignalRef, not .get() directly.

Common Pitfalls

`useComputedRef(() => ref.value * 2)`

Problem
This is purely Vue computation and will not enter the core reactive graph.

Fix
Read signal.get() inside the callback.

If you only need Vue computation, use Vue's computed.

Reading `signal.get()` directly in templates or `setup`

Problem
This is only a snapshot and will not update automatically.

Fix
Expose it as a ref using useSignalRef before passing it to templates.

Driving the same data with both Vue refs and signals

Problem
This easily creates circular scheduling and unexpected reruns.

Fix
Define a single source of truth (recommended: signals), and let Vue only display the value.

When to Use What?

Expose core state to templates
→ useSignalRef(signalOrComputed)

Create derived values inside a component
→ useComputedRef(() => signal.get() + ...)

Pure Vue computation or display
→ Vue computed

Observe value changes
→ useSignalRef → watch / watchEffect

Avoid:

calling .get() inside Vue effects
reading ref.value inside useComputedRef

Conclusion

If you've been following the series from the beginning, this workflow should now feel quite familiar.

For our signals system, frameworks are ultimately responsible only for binding data to UI rendering.
Creating an adapter is mainly a matter of practice.

Compared with React's unique behavior, Vue's template-based rendering model is actually closer to our mental model.

As long as you remember the following:

Vue only displays values via refs
dependency tracking and caching remain in the signals system

This approach avoids double dependency tracking and scheduler conflicts, while preserving the core advantage of:
push dirty-marking + pull recomputation

You can now stably integrate signals into Vue.

In the next article, we'll complete the story by covering interoperability and more advanced scenarios.

Signals in React (VI): Stale Closures, Subscription Traps, and Reactive Graph Pitfalls

Luciano0322 — Fri, 10 Apr 2026 01:53:24 +0000

Quick Overview

In the previous article, we discussed:

Why tearing occurs and how to guarantee tear-free subscriptions
How to avoid dangling subscriptions or computed nodes when components remount due to keys
Practical strategies for consistency and timing coordination when using Transition and Suspense

In this article, we will go through several examples to better understand common mistakes and their solutions.

Common Pitfalls

Stale closures: reading outdated values in events or async callbacks

Symptom
Values used inside setTimeout, debounce, or Promise.then are always outdated.

Cause
Event handlers and async callbacks capture the snapshot from the render that created them.

Fix
Read the snapshot again inside the callback using peek(), or inject a getter function to avoid closure persistence.

// ❌ onClick / timeout always uses "v from that render"
const v = useSignalValue(countSig);
const onClick = () => setTimeout(() => console.log(v), 500);

// ✅ read the latest value at callback time (no tracking)
const onClick2 = () => setTimeout(() => console.log(countSig.peek()), 500);

// ✅ or inject a getter
const getCount = () => countSig.peek();
const onClick3 = () => setTimeout(() => console.log(getCount()), 500);

Creating signal / computed instances inside component render

Symptom
Instances are recreated on every render, leading to subscription leaks or performance jitter.

Cause
Component functions execute on every render. Without useMemo or a custom hook, instances are not stable.

Fix
Use useSignalState, useComputed, or useMemo so the instance is created only once.

// ❌ recreated every render → guaranteed leak
function Bad() {
  const local = signal(0);
  const sum = computed(() => local.get() + 1);
}

// ✅ stable instances
function Good() {
  const [local, setLocal] = useSignalState(0);
  const sum = useComputed(() => local + 1);
}

Computed depending on React snapshots (won't update)

Symptom
useComputed(() => count * 2) runs only once and never updates.

Cause
computed only tracks signals accessed through .get() inside its callback.
React snapshot values are not part of the reactive graph.

Fix
Read signal.get() inside computed.
If you only need a render-time cache, use useMemo.

// ❌ not tracked
const count = useSignalValue(countSig);
const doubled1 = useComputed(() => count * 2);

// ✅ tracked via signal
const doubled2 = useComputed(() => countSig.get() * 2);

// ✅ render cache only
const doubled3 = React.useMemo(() => count * 2, [count]);

Manual subscriptions (`useEffect + setState`) causing tearing or excessive renders

Symptom
In Concurrent mode, UI and data become out of sync, or render counts spike.

Cause
If you manually create an effect inside useEffect and then call setState, React cannot re-read the snapshot before commit.

Fix
Always use useSignalValue or useSignalSelector, which internally rely on useSyncExternalStore.

// ❌ prone to tearing
useEffect(() => {
  const stop = createEffect(() => setV(src.peek()));
  return () => stop();
}, []);

// ✅ tear-free
const v = useSignalValue(src);

Misusing `.get()` during cleanup

Symptom
During cleanup, new dependency edges are accidentally created, leading to leaks or unexpected behavior.

Cause
Calling .get() inside onCleanup or React cleanup.

Fix
Use the previously captured snapshot or peek() to avoid tracking during cleanup.

createEffect(() => {
  const last = someComputed.peek(); // snapshot first

  onCleanup(() => {
    // ❌ avoid
    // someComputed.get();

    last; // ✅ use snapshot
    someComputed.peek(); // ✅ peek does not track
  });
});

Mixing sources leads to inconsistent UI

Symptom
Some UI elements update immediately, while others update later.

Cause
Some values are read from signals (immediate) while others use React state + Transition (deferred).

Fix
Unify the source of truth.

// ✅ read from signal, defer only in the UI
const q = useSignalValue(querySig);
const dq = useDeferredValue(q);

// ✅ buffer with React state, then commit to signal
const [draft, setDraft] = useState(useSignalValue(titleSig));
startTransition(() => titleSig.set(draft));

Key Concepts Recap

Reading values

Use:

useSignalValue
useSignalSelector

Building dependencies

Inside a computed callback, dependencies must be accessed via:

signal.get()

Instance lifecycle

Stabilize instances inside components using:

useSignalState
useComputed

Cleanup

During cleanup, use snapshots or peek(), and avoid .get().

Responsibility separation

UI / DOM side effects → React effects (useEffect)
Data side effects → our effects (createEffect)

Conclusion

With these examples, it should now be easier to grasp the practical characteristics of using Signals and more importantly, how to avoid common pitfalls.

At this point, we have completed a working core system and React integration:

Core

signal
effect
computed
push dirty-marking + pull recomputation
minimal scheduler with microtask batching

React Integration

useSignalValue
useComputed
useSignalSelector
built on useSyncExternalStore
correct effect separation and cleanup timing in Concurrent Mode / Strict Mode

What's Next

Next, we'll approach the same mental model from a different angle and bring it into Vue.

The good news is that the computed in this series is almost equivalent to Vue's computed, so the implementation will feel very natural.

Preview of the Next Article

We will implement two minimal hooks so Vue templates can directly use your state and derived values:

// vue-adapter
export function useSignalRef<T>(src: { get(): T; peek(): T }) {
  /* map to Vue ref, cleanup via onUnmounted */
}

export function useComputedRef<T>(fn: () => T, equals = Object.is) {
  /* create computed within lifecycle and convert to ref */
}

Important notes:

The callback of useComputedRef must read signal.get(), not ref.value, otherwise it becomes a pure Vue computation and loses your reactive graph.
The bridge only synchronizes values to Vue refs, and does not reconnect Vue's reactivity back into your graph, avoiding circular scheduling dependencies.
Cleanup uses onUnmounted, so unmounting releases the associated createEffect or computed.

Signals in React (V): Avoiding Tearing, Remount Leaks, and Transition Pitfalls

Luciano0322 — Mon, 30 Mar 2026 01:02:13 +0000

Goal of This Article

In this article, we will focus on three practical issues when integrating signals with React:

Understanding why tearing happens and how to guarantee tear-free subscriptions
Avoiding stale subscriptions and leftover computed nodes when components remount due to key changes
Handling consistency and timing coordination in Transition and Suspense scenarios

Data Flow and Responsibility Boundaries

The diagram below summarizes how data flows when signals are used inside a React environment.

We can divide responsibilities clearly:

Data side effects → our createEffect (business logic)
UI / DOM side effects → React’s useLayoutEffect / useEffect
Reading values → always through useSignalValue (useSyncExternalStore + peek() for tear-free behavior)

Tearing: Cause and Solution

We discussed tearing earlier, but let’s briefly recap.

Under React Concurrent Mode, React may read snapshots multiple times between render and commit.

If your snapshot is not controlled by React (for example, directly calling someSignal.get()), the UI may render with a snapshot that no longer matches the DOM after commit.

React’s Snapshot mechanism is a compromise to coordinate state updates and UI rendering.
It is not part of JavaScript itself, which is why some React developers develop incorrect mental models about JavaScript behavior.

Earlier chapters reviewed some JavaScript fundamentals to avoid this confusion. If you joined the series midway, it may be helpful to revisit those sections.

Two Common Incorrect Patterns

1. Reading `.get()` directly in a component

function Bad() {
  const v = someSignal.get(); // snapshot not controlled by React
  return <div>{v}</div>;
}

2. Manual subscription using `useState + useEffect`

function Bad() {
  const [v, setV] = useState(someSignal.peek());

  useEffect(() => {
    const stop = createEffect(() => {
      setV(someSignal.peek());
    }); // snapshot not re-read before commit

    return () => stop();
  }, []);

  return <div>{v}</div>;
}

Correct Approach: `useSyncExternalStore`

Always use useSyncExternalStore through our useSignalValue hook.

function Good() {
  const v = useSignalValue(someSignal); // tear-free
  return <div>{v}</div>;
}

Avoiding Unnecessary Re-renders: `useSignalSelector`

const user = signal({ id: 1, name: "Ada", age: 37 });

// Only re-render when name changes
function Name() {
  const name = useSignalSelector(user, u => u.name);
  return <h2>{name}</h2>;
}

Guidelines

Never call .get() during render
Always use useSignalValue or useSignalSelector
Do not implement subscriptions manually
useSyncExternalStore automatically re-reads the snapshot before commit and guarantees tear-free behavior

Remounting with `key`: Avoiding Stale Subscriptions and Memory Leaks

The Situation

When list keys change or routing switches occur, React will:

Unmount the old tree
Mount a new one

The Risk

If your derived values (computed / effect) have long lifetimes and live in module scope, their graph connections may still exist.

Problematic Example

export const expensive = computed(() => a.get() + b.get());

Even if some pages no longer need this value, upstream signals a and b may still retain subscriptions.

Solution

1. Bind to component lifecycle using `useComputed`

function Page() {
  const sum = useComputed(() => aSig.get() + bSig.get());
  const v = useSignalValue(sum);
  return <div>{v}</div>;
}

When the component unmounts, useComputed will automatically dispose the node.

2. Containerize with a Provider

const Ctx = createContext<{ sum: ReturnType<typeof computed> } | null>(null);

function StoreProvider({ children }: { children: React.ReactNode }) {
  const sum = useMemo(() => computed(() => aSig.get() + bSig.get()), []);

  useEffect(() => () => sum.dispose?.(), [sum]);

  return (
    <Ctx.Provider value={{ sum }}>
      {children}
    </Ctx.Provider>
  );
}

function Child() {
  const store = useContext(Ctx)!;
  const v = useSignalValue(store.sum);
  return <div>{v}</div>;
}

Practical Rule

Derived values under UI nodes → use useComputed
Global derived values → manage them with a Provider

Important Note About `computed`

computed is a node in the reactive graph (Observer + Trackable).

Dependencies are tracked only when signal.get() is called inside its callback.

If you pass React snapshots into useComputed, the computed node will not track any signals.

Incorrect Example

const count = useSignalValue(countSig);
const doubled = useComputed(() => count * 2); 
// computed runs once and never updates

Correct Example

const count = useSignalValue(countSig);
const doubled = useComputed(() => countSig.get() * 2);

Alternative: Pure React derivation

const count = useSignalValue(countSig);

const doubled = React.useMemo(() => count * 2, [count]);
// not part of the reactive graph

Transitions: Consistency and Timing Coordination

Important point:

startTransition only affects React's setState priority.

It does not delay signal writes.

If some UI reads signals (useSignalValue) while other parts use setState + Transition, you may observe inconsistent UI timing.

Two Safe Strategies

Strategy 1: Always read external snapshots

All UI reads signals through useSignalValue.

For transition-like behavior, use useDeferredValue for display delay, rather than delaying data writes.

function SearchBox() {
  const q = useSignalValue(querySig);
  const deferredQ = useDeferredValue(q);

  return (
    <>
      <input
        value={q}
        onChange={e => querySig.set(e.target.value)}
      />
      <ExpensiveList query={deferredQ} />
    </>
  );
}

Strategy 2: Keep transitional values inside React state

A. React state as draft buffer

function Editor() {
  const committed = useSignalValue(titleSig);
  const [draft, setDraft] = useState(committed);

  useEffect(() => setDraft(committed), [committed]);

  const save = () => {
    startTransition(() => {
      titleSig.set(draft);
    });
  };

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

Use this when you want to separate typing UI updates from heavy re-renders after commit.

B. Local signal state

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

  useEffect(() => setDraft(committed), [committed]);

  const save = () => {
    titleSig.set(draft);
  };

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

During editing, only the local signal updates, so downstream computations are unaffected.

C. Immediate writes but delayed UI

If you must update the signal on every keystroke, use useDeferredValue for expensive UI sections.

function Search() {
  const q = useSignalValue(querySig);
  const deferredQ = useDeferredValue(q);

  return (
    <>
      <input
        value={q}
        onChange={e => querySig.set(e.target.value)}
      />
      <ExpensiveList query={deferredQ} />
    </>
  );
}

The data stays real-time, while the UI update is deferred.

Common Misunderstandings

"If I use useSignalState, I no longer need startTransition?"

Usually yes.
Because useSignalState stores values locally and does not trigger global signal updates.

However, if committing still triggers heavy React state updates, those setState calls can still be wrapped in startTransition.

"If I wrap signal.set() inside startTransition, will it lower priority?"

No.
Transitions do not affect external stores.

Updates from external stores trigger re-renders through useSyncExternalStore, independent of startTransition.

Suspense: Consistency When Data Is Not Ready

Reality: signals do not automatically integrate with React Suspense.
Suspense only recognizes data sources that throw a Promise during render.

Strategy A: State-driven approach (simpler)

Data layer

const userId = signal(1);

const user = signal({
  status: "idle",
});

createEffect(() => {
  const id = userId.get();

  user.set({ status: "loading" });

  fetch(`/api/user/${id}`)
    .then(r => r.json())
    .then(d => user.set({ status: "ok", data: d }))
    .catch(e => user.set({ status: "error", err: e }));
});

function UserPanel() {
  const u = useSignalValue(user);

  if (u.status === "loading") return <Spinner />;
  if (u.status === "error") return <ErrorView err={u.err} />;

  return <Profile data={u.data} />;
}

Strategy B: Convert into a Suspense resource

export function toResource(src) {
  let thrown = null;

  return {
    read() {
      const s = src.peek();

      if (s.status === "ok") return s.data;
      if (s.status === "error") throw s.err;

      if (!thrown) thrown = new Promise(() => {});
      throw thrown;
    }
  };
}

function UserPanel() {
  const resource = React.useMemo(() => toResource(user), []);

  const data = resource.read();

  return <Profile data={data} />;
}

<React.Suspense fallback={<Spinner />}>
  <UserPanel />
</React.Suspense>

When to choose which?

If your project does not heavily rely on Suspense → Strategy A is simpler

If you already have Suspense infrastructure → Strategy B works with an adapter

Just remember to provide a real pending Promise.

Conclusion

At this point, you can use your signals in React 18+ with:

Stable tear-free subscriptions
Minimal unnecessary re-renders
Clear responsibility boundaries between React and signals

In the next article, we will look at common anti-patterns and how to fix them.

Signals in React(IV): Separating UI Effects and Data Effects with Signals

Luciano0322 — Thu, 26 Mar 2026 02:24:37 +0000

Quick Recap

This article continues from the conclusion of the previous one.

We will look at practical examples to understand how React and signals can complement each other in real applications.

Effect Cleanup Strategies

First, let’s clarify the core concept:

Our effect (createEffect) is responsible for data/business cycles. It depends on signals and releases resources using onCleanup before re-running.
React effects (useEffect / useLayoutEffect) are responsible for UI/DOM cycles. They depend on React snapshots (props/state) and clean up before the next commit.

Practical Examples

Timer Example (using `createEffect`)

Requirement

Poll data based on an adjustable intervalMs and write the latest time into a heartbeat signal.

Key idea

When intervalMs changes, the old setInterval should be automatically cleared and replaced with a new one.

// data/heartbeat.ts
import { signal } from "../core/signal";
import { createEffect, onCleanup } from "../core/effect";

export const intervalMs = signal(1000);
export const heartbeat = signal<Date | null>(null);

createEffect(() => {
  const ms = intervalMs.get(); // depend on signal
  const id = setInterval(() => {
    heartbeat.set(new Date()); // write back to the data layer
  }, ms);

  onCleanup(() => clearInterval(id)); // release before next re-run
});

Why place this inside createEffect?

This is purely a data-layer task:

it depends on signals and writes back to signals.
It does not interact with the DOM and does not require React’s commit timing.

UI Blinking Example (using `useEffect`)

Requirement

Make a cursor blink every 500ms.

Key idea

Since this behavior is tightly coupled to the DOM/rendering, it should be managed by React’s lifecycle.

// ui/Blinker.tsx
import { useState, useEffect } from "react";

export function Blinker({ enabled = true }) {
  const [on, setOn] = useState(false);

  useEffect(() => {
    if (!enabled) return;
    const id = setInterval(() => setOn(v => !v), 500);
    return () => clearInterval(id); // cleanup before next commit
  }, [enabled]);

  return <span className={on ? "caret on" : "caret"}>|</span>;
}

Why place this inside useEffect?

This is purely a UI/visual behavior:
it depends on React state/props, and its cleanup timing should follow React’s commit cycle.

Using Them Together Without Interference

// App.tsx
import { useSignalValue } from "./react-adapter";
import { heartbeat, intervalMs } from "../data/heartbeat";
import { Blinker } from "./ui/Blinker";

export function Dashboard() {
  const lastBeat = useSignalValue(heartbeat);
  const ms = useSignalValue(intervalMs);

  return (
    <section>
      <h3>Last heartbeat: {lastBeat?.toLocaleTimeString() ?? "—"}</h3>
      <p>Polling every {ms} ms</p>
      <Blinker enabled /> {/* UI timer managed by React */}
    </section>
  );
}

Timer polling (createEffect) exists independently of any component and continues even across page navigation.

UI blinking (React useEffect) is created and cleaned up along with component mount/unmount.

The cleanup timing does not conflict:

createEffect → onCleanup runs before re-execution
React useEffect → cleanup runs before the next commit

Common Mistakes and Fixes

Mistake: Using createEffect to control DOM timers

createEffect(() => {
  const id = setInterval(() => {
    el.classList.toggle("on"); // DOM timing not controlled by React
  }, 500);

  onCleanup(() => clearInterval(id));
});

Fix: Let React manage it with useEffect

(See the Blinker example above)

Mistake: Using React useEffect for data polling and directly using a signal as dependency

// Only runs once on mount, will not rebuild when interval changes
React.useEffect(() => {
  const id = setInterval(fetchData, ms /* passing signal directly */);
  return () => clearInterval(id);
}, []); // empty deps

Fix: Two possible approaches

A) Use the hook we created to obtain a snapshot

const ms = useSignalValue(intervalMs);

React.useEffect(() => {
  const id = setInterval(fetchData, ms);
  return () => clearInterval(id);
}, [ms]);

B) Move it back to the data layer with createEffect

Do not call signal functions directly inside React components.
Keep signals outside the component closure to maintain a clean separation.
When you need to read signals inside React, use hooks to access them.

Quick Concept Summary

Scenario	Recommended Location	Dependency Source	Cleanup Timing
Data polling, cache updates, writing to signals	our effect	signal.get()	onCleanup before rerun
Visual effects, DOM operations, measurements	React effect	React state/props	cleanup before next commit
Batching multiple synchronous set() calls	scheduler (built-in microtask)	—	microtask flush
Read current value without reverse dependency	useSignalValue / peek()	not tracked	—

Understanding Through Mental Models

Responsibilities of Each Layer

Cleanup Order (during a single update)

FAQ

Q: Why does `getSnapshot` use `peek()` instead of `get()`?

A:
To avoid adding the React component itself to the reactive graph’s subs.
peek() will still perform lazy recomputation when the signal is stale, so the snapshot remains up to date.

Q: Can I call `createEffect` inside the render phase (inside a function component)?

A:
It’s best not to.
The adapter should create and clean up subscriptions through subscribeReadable within the useSyncExternalStore lifecycle.

Q: Do I need to manually batch multiple synchronous `set()` calls?

A:
No. Our scheduler already merges updates within the same tick into a single microtask.
Cross-await batching will be discussed in the advanced section (transaction(async)).

Conclusion

With the examples above, it should be clearer how signals can complement React.

From a usage perspective, the experience may feel similar to libraries like Jotai or Zustand, but signals provide finer-grained control, are not tied to a specific framework, and therefore offer higher compatibility across environments.

In the next article, we will cover practical patterns and checklists for handling:

key-based remounting
stale closures
consistency of values read during Transitions

With concrete patterns you can directly apply.

Signals in React (III): Lifecycle Never Disappeared

Luciano0322 — Mon, 23 Mar 2026 01:52:24 +0000

The Lifecycle Never Went Away

From the beginning of this series up to the current implementation, everything has revolved around the lifecycle of the data layer:

How data is read, invalidated, recomputed, and when side effects are triggered.

This does not conflict with the framework’s lifecycle. In fact, React never removed lifecycle — it restructured it into two distinct phases:

Render: Purely computes UI. It may run multiple times, be interrupted, or discarded. Ideally, no side effects should occur here.
Commit: Applies changes to the DOM in a single, synchronous step. useLayoutEffect / useEffect setup and cleanup run here. This is the only legitimate place for UI side effects.

If you’re not familiar with useLayoutEffect and useEffect, review how React manages mount/unmount timing via these hooks. That understanding is foundational.

React emphasizes that in typical usage, UI dependencies on state are not explicitly declared. When state updates, React re-runs the component render and uses VDOM diffing to determine minimal DOM changes. Whether child subtrees update depends on bailout and memoization strategies.

Signals take a different route: an explicit dependency graph.

The system knows who depends on whom, allowing precise update propagation. A scheduler (e.g., microtask batching) controls when side effects run.

The two approaches may look different, but both rigorously manage lifecycle boundaries:

React protects side-effect timing via the Render/Commit boundary.
Signals manage data lifecycle through invalidation, recomputation, and subscription boundaries.

The lifecycle never disappeared — it simply exists at different abstraction layers.

Goal of This Article

We clearly separate responsibilities:

UI-related side effects (DOM measurement, manipulation, animation) → React (useLayoutEffect / useEffect)
Data-flow side effects (business logic triggered by signal/computed changes) → signals (createEffect, lifecycle managed by our adapter)
Render must remain pure — no signal.set() or external effect creation during render.

Timing Overview: Who Runs First? Who Cleans First?

React effect cleanup (useEffect / useLayoutEffect) runs before the next commit.

Our signal effect cleanup (onCleanup) runs before re-execution within the same microtask batch.

They operate independently and do not conflict.

Responsibility Separation

Concern	Where It Belongs	Explanation
Read/write DOM, measurement, animation	`useLayoutEffect` / `useEffect`	Runs after commit, timing is predictable
Trigger business logic (requests, logging, cross-layer events)	`createEffect` (via adapter subscription)	Scheduler batches and re-runs in microtasks
Merge multiple synchronous `set()` calls	Scheduler (microtask dedupe)	Effects re-run only once per batch
Read current snapshot	`useSignalValue` / `useComputed`	`useSyncExternalStore + peek()` prevents tearing in Concurrent mode

Correct Usage Patterns

1. Writing During Render vs Writing in Event / Effect

❌ Incorrect (side effect during render)

function Bad() {
  const v = useSignalValue(mySig);
  if (v < 0) mySig.set(0); // Writing during render → infinite re-render / StrictMode issues
  return null;
}

✅ Correct (write in React effect)

function Good() {
  const v = useSignalValue(mySig);

  React.useEffect(() => {
    if (v < 0) mySig.set(0);
  }, [v]); // Safe: runs after commit

  return null;
}

Or inside an event handler:

<button onClick={() => mySig.set(x => Math.max(0, x))}>
  Clamp
</button>

This mirrors a common React rule: never mutate state during function component render.

2. DOM Manipulation in Our Effect vs React Effect

❌ Incorrect (DOM mutation inside our effect)

createEffect(() => {
  const h = panelHeight.get();
  panelEl.style.height = h + "px"; // May conflict with React commit
});

✅ Correct (pass value to React; mutate DOM in layout effect)

function Panel({ el }: { el: HTMLElement }) {
  const h = useSignalValue(panelHeightSignal);

  React.useLayoutEffect(() => {
    el.style.height = h + "px"; // Safe: runs after commit
  }, [el, h]);

  return null;
}

The DOM lifecycle belongs to React.
Our effects are better suited for data-level side effects.

3. `useEffect` Subscription vs `useSyncExternalStore`

❌ Incorrect (manual subscription via useEffect → tearing risk)

function BadSubscribe() {
  const [v, setV] = React.useState(mySig.peek());

  React.useEffect(() => {
    const stop = createEffect(() => {
      setV(mySig.peek()); // May cause tearing
    });
    return () => stop();
  }, []);

  return <div>{v}</div>;
}

✅ Correct (use adapter hook built on useSyncExternalStore)

function GoodSubscribe() {
  const v = useSignalValue(mySig); // useSyncExternalStore + peek()
  return <div>{v}</div>;
}

useSyncExternalStore guarantees snapshot consistency under Concurrent rendering, preventing tearing.

(For older React versions, a third-party shim can be considered.)

4. Computed Depending on React Snapshot vs Signal

❌ Incorrect (computed depends on React value)

const count = useSignalValue(countSig);
const doubled = useComputed(() => count * 2); // Only runs once

This does not establish a dependency in the reactive graph.

✅ Correct (computed reads signal directly)

const count = useSignalValue(countSig);
const doubled = useComputed(() => countSig.get() * 2); // Dependency tracked

Or use pure React derivation when no reactive node is needed:

const count = useSignalValue(countSig);
const doubled = useMemo(() => count * 2, [count]);

A computed must call .get() inside its execution to be tracked.

Lessons from These Mistakes

From the examples above, we can extract clear principles:

Render must remain pure — no createEffect or signal.set() during render.
UI side effects → useLayoutEffect / useEffect.
Data side effects → createEffect.
Always subscribe via useSignalValue (useSyncExternalStore).
computed must read .get(), not React snapshots.

Conclusion

React Effects include UI rendering updates.
If we want our signal system to work correctly within React, integration must respect React’s lifecycle hooks.

In short:

APIs from our mechanism should accept signals directly.
Values wrapped via hooks take on React’s shape, and therefore must interact through React hooks.

Only then will dependency tracking behave correctly.

In the next article, we’ll look at concrete examples demonstrating how both systems can complement each other.

Signals in React (II): Tear-Free Subscriptions

Luciano0322 — Wed, 18 Mar 2026 01:36:56 +0000

Goal of This Article

Integrate our previously implemented signal / omputed system into React 18 Concurrent Mode in a tear-free way.

The key principle:

Snapshot reading + subscription must be handled by useSyncExternalStore.

Why Does Tearing Happen?

In React 18, the render phase can be interrupted, restarted, and replayed.

If you read mutable external data directly during render (ex: someSignal.get()) and that data changes before the commit phase finishes, the DOM may reflect a different state than the snapshot React rendered with.

This inconsistency is called tearing:

The rendered output and the underlying snapshot are no longer synchronized.

The `useSyncExternalStore` Solution

React provides a built-in mechanism specifically designed to prevent tearing:

getSnapshot → synchronous snapshot reader
subscribe → notify React when data changes

React will re-read the snapshot right before commit to ensure consistency.

This is the only officially supported way to safely connect external mutable state to Concurrent React.

What We Need for Our Signal System

To integrate properly:

1️⃣ Snapshot Source: `peek()`

peek() does not establish reactive tracking.
If the computed value is stale, it still lazily recomputes.
It guarantees we always read the latest value.

2️⃣ Subscription Mechanism: `createEffect`

Inside the effect, we call signal.get() to establish dependency tracking.
When dependencies change, we call notify() from useSyncExternalStore.

3️⃣ Avoid `setState` During Initial Render

The first subscription execution must not trigger notify(),
otherwise we would cause setState during render.

Hook Implementation

import { useEffect, useMemo, useSyncExternalStore, useRef } from "react";
import { createEffect } from "../core/effect.js";
import { computed } from "../core/computed.js";
import { signal } from "../core/signal.js";

type Readable<T> = { get(): T; peek(): T };

function subscribeReadable<T>(src: Readable<T>, notify: () => void) {
  let first = true;

  const stop = createEffect(() => {
    src.get(); // track dependencies
    if (first) {
      first = false;
      return;
    }
    notify(); // notify React only after first run
  });

  return () => stop();
}

`useSignalValue`

export function useSignalValue<T>(src: Readable<T>) {
  const getSnapshot = () => src.peek();

  return useSyncExternalStore(
    (notify) => subscribeReadable(src, notify),
    getSnapshot, // client
    getSnapshot  // server (SSR)
  );
}

`useComputed`

export function useComputed<T>(
  fn: () => T,
  equals: (a: T, b: T) => boolean = Object.is
) {
  const fnRef = useRef(fn);
  fnRef.current = fn;

  const eqRef = useRef(equals);
  eqRef.current = equals;

  const memo = useMemo(() => {
    const c = computed(
      () => fnRef.current(),
      (a, b) => eqRef.current(a, b)
    );
    c.get(); // warm-up
    return c;
  }, []);

  useEffect(() => () => memo.dispose?.(), [memo]);

  return useSignalValue(memo);
}

`useSignalState`

export function useSignalState<T>(initial: T) {
  const sig = useMemo(() => signal<T>(initial), []);
  const value = useSignalValue(sig);
  return [value, sig.set] as const;
}

`useSignalSelector`

export function useSignalSelector<S, T>(
  src: Readable<S>,
  selector: (s: S) => T,
  isEqual: (a: T, b: T) => boolean = Object.is
) {
  const selectorRef = useRef(selector);
  selectorRef.current = selector;

  const eqRef = useRef(isEqual);
  eqRef.current = isEqual;

  const memo = useMemo(() => {
    const c = computed(
      () => selectorRef.current(src.get()),
      (a, b) => eqRef.current(a, b)
    );
    c.get();
    return c;
  }, [src]);

  useEffect(() => () => memo.dispose?.(), [memo]);

  return useSignalValue(memo);
}

Usage Examples

Counter Example

import { useSignalState, useComputed } from "./react-adapter";

export function Counter() {
  const [count, setCount] = useSignalState(0);
  const doubled = useComputed(() => count * 2);

  return (
    <div>
      <p>{count} / {doubled}</p>
      <button onClick={() => setCount(v => v + 1)}>+1</button>
    </div>
  );
}

Bottom-Up Global State

const countSignal = signal(0);

export function Counter() {
  const count = useSignalValue(countSignal);
  const doubled = useMemo(() => count * 2, [count]);

  return (
    <div>
      <p>{count} / {doubled}</p>
      <button onClick={() => countSignal.set(v => v + 1)}>+1</button>
    </div>
  );
}

Selector Example

const user = signal({ id: 1, name: "Ada", age: 37 });

export function ProfileName() {
  const name = useSignalSelector(user, u => u.name);
  return <h2>{name}</h2>;
}

Multiple `set()` Calls Are Batched

function Buttons() {
  const [a, setA] = useSignalState(0);
  const [b, setB] = useSignalState(0);
  const sum = useComputed(() => a + b);

  const clickFn = () => {
    setA(v => v + 1);
    setB(v => v + 1);
  };

  return (
    <>
      <p>sum = {sum}</p>
      <button onClick={clickFn}>
        +A & +B
      </button>
    </>
  );
}

Our scheduler merges multiple set() calls within the same call stack into a single microtask.

So only one effect re-execution occurs.

StrictMode & Concurrent Safety Checklist

✅ Do not call notify() on first subscription
✅ Disposer must be re-entrant (StrictMode mounts → unmounts → mounts again)
✅ getSnapshot must be pure (no side effects)
✅ Do not create external effects during render
✅ Lifecycle must be managed by useSyncExternalStore

Common Pitfalls

❌ Subscribing via `useEffect`

useEffect(() => {
  const stop = createEffect(() => { 
    someSignal.get();
    setState(someSignal.peek());
  });
  return () => stop();
}, []);

This can cause synchronization issues.

✅ Correct Solution

const value = useSignalValue(mySignal);

React will re-check the snapshot before commit, preventing tearing.

❌ Capturing `get()` in a Closure

const v = someSignal.get();
const onClick = () => console.log(v);

This creates a stale closure.

✅ Correct Solution

const latest = useSignalValue(someSignal);
const onClick = () => console.log(latest);

Mental Model

Any state value that should participate in React-driven updates
must go through a hook so React can track it within its lifecycle.

Interacting with Batch / Transaction

batch and transaction only affect our internal effect scheduling.

They do not interfere with React’s render/commit phases.

Inside an event:

transaction(() => {
  a.set(...);
  b.set(...);
});

React batches its own state updates.
Our effects rerun only once (microtask).
useSignalValue() reads the latest lazily recomputed value.

Conclusion

With these hooks, we can now safely use our custom fine-grained Signal system inside React — fully compatible with Concurrent Mode, StrictMode, and SSR.

And we achieve this without sacrificing granular reactivity.

In the next article, we’ll explore how to reason about side-effect integration at a deeper level.

Signals in React (I): Without Breaking the Render Model

Luciano0322 — Wed, 11 Mar 2026 02:03:09 +0000

Why Does the Framework Affect How You Use Signals?

The short answer is lifecycle.

On social platforms, you’ll often see a group of React developers pretending lifecycle doesn’t exist while selling courses. That honestly worries me a bit—but once you go deep enough, you’ll realize this is mostly marketing rhetoric.

After implementing our signal system step by step in previous articles, you should already have a solid intuition for what lifecycle actually means. In this article, we’ll clarify three key points:

1. Two-phase mental model
React has Render and Commit.
Render can run multiple times and be interrupted; only Commit mutates the DOM.

2. Timing alignment
Our signals merge side effects in microtasks via a scheduler.
React uses event batching and Concurrent rendering.

3. Forbidden zones and correct placement
What must not happen during React’s render phase (e.g. createEffect, signal.set)—and where these belong instead.

TL;DR

In React, render must be pure (the Function Component contract). Do not perform side effects or write to signals during render.
Side-effect responsibility split:
- UI-related (DOM measurement, animations) → useLayoutEffect / useEffect
- Data-flow related (business logic triggered by signals, requests) → createEffect (managed via a React adapter)
Subscriptions must go through useSyncExternalStore (covered next article) to avoid tearing.

React vs Signals: Timing Differences

React render may run many times (Concurrent mode, StrictMode). Commit runs only once.
Our scheduler merges effects at the microtask boundary.
Therefore: never create or trigger createEffect during render. Let hooks manage lifecycle instead.

StrictMode and Concurrent Traps

StrictMode (development only)

React will:

create → immediately clean up → create again

This is intentional—to detect side effects during render.

Concurrent Rendering

Render can be interrupted and restarted.
Reading external mutable state during render can cause tearing.

Official recommendation:
Use useSyncExternalStore to provide snapshots + subscriptions.
React can re-read the snapshot before commit, preventing tearing.

What Not to Do

Creating `createEffect` during render

function Bad() {
  // Creating external effects during render breaks purity and predictability
  createEffect(() => {
    console.log("value", someSignal.get());
  });
  return <>{/* ...your UI */}</>;
}

Writing to signals during render

function Bad() {
  const v = someSignal.get();
  if (v < 0) someSignal.set(0); // Writing during render → infinite re-renders
  return <>{/* ...your UI */}</>;
}

Capturing `get()` values in long-lived closures

function Bad() {
  const v = someSignal.get();  // snapshot at render time
  const onClick = () => console.log(v); // always logs stale value
  return <button onClick={onClick}>log</button>;
}

Correct Patterns

Subscriptions

Wrap signals with useSyncExternalStore → useSignalValue(src)
Use peek() for snapshots:
- No React → signal dependency
- Lazy recompute when stale
Inside subscribe, use createEffect to track changes
Clean up effects on unmount

Writes

Perform writes in event handlers or React effects
Never during render

DOM Side Effects

Still go through useLayoutEffect / useEffect
Pass signal values into React
Let React control DOM timing

We won’t implement this yet—this section is to establish the mental model first.

React Batching vs Our `batch`

React batches setState calls inside event handlers.

Our batch:

Only affects signal effect scheduling
Does not interfere with React’s commit phase

Example

batch(() => {
  a.set(10);
  b.set(20);
  a.set(30);
});

// Our effects rerun once in a microtask
// React setState (if any) still batches render once per event

Side-Effect Responsibility Table

Task	Where to Put It	Why
DOM reads/writes, measurement, animation	`useLayoutEffect` / `useEffect`	Controlled by React’s Commit phase
Business effects triggered by signals	`createEffect` (via hooks)	Scheduler merges reruns
Multiple updates, single rerun	`batch` / `transaction`	Affects signals only
React subscribing to external state	`useSyncExternalStore`	Prevents tearing, supports Concurrent
Immediate effect flush (tests/demos)	`flushSync()` (ours)	Clears scheduler immediately

Incorrect vs Correct

❌ Wrong: Subscribing + updating React state manually

function Bad() {
  const [state, setState] = useState();
  const v = someSignal.get();

  useEffect(() => {
    // Prone to tearing and duplicate updates
    const stop = createEffect(() => {
      someSignal.get();
      setState(Date.now());
    });
    return () => stop();
  }, []);

  return <div>{v}</div>; // v is not a React-managed snapshot
}

✅ Correct: Use `useSyncExternalStore`

function Good() {
  // Implemented in the next article
  const v = useSignalValue(someSignal);
  return <div>{v}</div>; // React-controlled synchronous snapshot
}

Conclusion

With these concepts in place, you should now have a more accurate understanding of React’s rendering and update mechanics.

Our goal is not to replace React’s state system.

Instead, we treat signals as external data sources—integrated in a way that:

avoids tearing in Concurrent mode
minimizes unnecessary reruns
keeps behavior predictable

In the next article, we’ll implement the missing pieces and show how to correctly integrate our signal system into React.

Forem: Luciano0322

I published a new article on atomic transactions for signals. The core idea: all succeed, or nothing changes. I also covered rollback, nested transactions, and React/Vue examples.

Building Atomic Transactions with Rollback for Signals

Building Atomic Transactions with Rollback for Signals

What Is an Atomic Transaction?

Behavior Definition

API and File Structure

Extending scheduler.ts

Consistency Guarantees

Adjustments in signal.ts

Usage Scenarios

Inner transaction fails, outer transaction continues

Outer transaction fails

React / Vue Examples

Using Atomic Transactions with Rollback in React

Using Atomic Transactions with Rollback in Vue

Execution Timeline (Success vs Failure)

Closing Thoughts

New article in my signal-kernel series: Async Transactions for Signals How do you batch updates across await boundaries without breaking lazy computed or your scheduler model? This article shows the implementation and the trade-offs.

Async Transactions for Signals: Batching Updates Across await

Async Transactions for Signals: Batching Updates Across await

Introduction

Quick Overview

Why Do We Need Async Transactions?

Without vs. With Transaction

Minimal Change: Extending scheduler.ts

Core Idea

Behavioral Guarantees

computed Is Still Lazy

Effects Run Once After the Transaction Ends

Nesting Is Supported

Exception-Safe

Usage Guide

Using It in React

Multi-Step Updates Across await

Local Draft + Commit Once on Submit

Using It in Vue

Multi-Step Updates Across await in an SFC

Local Draft + Commit Once on Submit

Conceptual Summary

Data Layer

UI Layer

Draft Pattern

Understanding the Timeline Across await

Conclusion

Signals in Vue (II): Interop, Async Patterns, SSR, and Common Pitfalls

Quick Overview

watch / watchEffect: who should observe what?

Guiding principles

Comparison example

Remounts with key: lifecycle matters

Solution A: component-scoped useComputedRef

Solution B: containerize the lifecycle with a Provider

Async data

Approach A: state-driven rendering

Approach B: Suspense resource

SSR / Hydration: snapshot and subscription timing

SSR-compatible example

Equality strategy and performance: equals and normalized writes

Common pitfalls and fixes

Reading ref.value inside useComputedRef

Calling .get() directly in the template or in setup

Using watchEffect to read .get()

Module-scoped computed values that are never cleaned up

Expecting Vue <Transition> / animations to delay data writes

Closing thoughts

Signals in Vue (I): A Minimal Bridge to the Composition API

Quick Recap

Goal of This Article

Design Principles

One-way bridge

Clear lifecycle

Snapshot source

Consistent mental model

Who Depends on Whom (Vue Version)

Implementing the Adapter

Why shallowRef?

Update and Cleanup Timing

Usage Example (SFC)

Counter: signal + derived value

Extending `scheduler.ts`

Adjustments in `signal.ts`

Minimal Change: Extending `scheduler.ts`

`computed` Is Still Lazy

Multi-Step Updates Across `await`

Multi-Step Updates Across `await` in an SFC

Understanding the Timeline Across `await`

`watch` / `watchEffect`: who should observe what?

Remounts with `key`: lifecycle matters

Solution A: component-scoped `useComputedRef`

Equality strategy and performance: `equals` and normalized writes

Reading `ref.value` inside `useComputedRef`

Calling `.get()` directly in the template or in `setup`

Using `watchEffect` to read `.get()`

Expecting Vue `<Transition>` / animations to delay data writes

Why `shallowRef`?

Interoperability with `watch` / `watchEffect`

`useComputedRef(() => ref.value * 2)`

Reading `signal.get()` directly in templates or `setup`

Manual subscriptions (`useEffect + setState`) causing tearing or excessive renders

Misusing `.get()` during cleanup

1. Reading `.get()` directly in a component

2. Manual subscription using `useState + useEffect`

Correct Approach: `useSyncExternalStore`

Avoiding Unnecessary Re-renders: `useSignalSelector`

Remounting with `key`: Avoiding Stale Subscriptions and Memory Leaks

1. Bind to component lifecycle using `useComputed`

Important Note About `computed`