Forem: Luciano0322

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.

Why Batch Belongs to the Scheduler, Not Computed

Luciano0322 — Wed, 04 Mar 2026 05:46:56 +0000

Recap

Building on the previous articles—signal, effect, and computed—we have already made the timing of side-effect execution much more controllable:

Multiple set() calls are merged → an effect reruns only once per flush cycle
Updating multiple signals in one block → avoids intermediate “flickering” states
Reading inside a block always returns the latest value (because set() writes synchronously, and computed recomputes lazily on get())

Why Do We Need `batch`?

A key design principle here is:

computed stays lazy.
batch / transaction only adjust effect scheduling (push merging).
They never force eager recomputation.

In other words:

computed decides when to compute
batch decides when side effects run

Design Approach

We modularize scheduling logic into a dedicated scheduler module to handle:

Deduplication
Microtask merging
Batching
flushSync support

Components

scheduler.ts: A minimal scheduler (dedupe, microtask merging, batch / flushSync support)
batch(fn): Wraps a sequence of updates and flushes effects at the end
transaction(fn): Currently identical to batch(fn) (introduced mainly for testing; extensible later)
effect: only one-line change schedule() → scheduleJob(this)

Extracting the Scheduler

Previously, we embedded Set + queueMicrotask + flush logic directly inside EffectInstance.
Now we extract it into a standalone module for clearer semantics and easier extensibility.

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

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

// Add a job to the queue.
// If not inside a batch, schedule a microtask flush.
export function scheduleJob(job: Schedulable) {
  if (job.disposed) return;
  queue.add(job);

  if (!scheduled && batchDepth === 0) {
    scheduled = true;
    queueMicrotask(flushJobs);
  }
}

// Merge multiple updates into a single effect flush
export function batch<T>(fn: () => T): T {
  batchDepth++;
  try {
    return fn();
  } finally {
    batchDepth--;
    if (batchDepth === 0) flushJobs();
  }
}

// Immediately flush the queue (useful for tests)
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");
    }
  }
}

Effect Integration (One-Line Change)

// effect.ts
import { scheduleJob } from "./scheduler";

export class EffectInstance {
  /* existing members and run() unchanged */

  schedule() {
    scheduleJob(this); // previously: push into Set + queueMicrotask
  }
}

No changes are required for:

signal.set()
- still:
  - schedules effects
  - marks computed values as stale
computed.get()
- still recomputes lazily on demand

Batch & Transaction Semantics

`batch(fn)`

Inside a batch:
- scheduleJob only queues effects
- no microtask is scheduled
When exiting the outermost batch:
- flushJobs() runs once
Nested batches still flush only once

import { batch } from "./scheduler";

batch(() => {
  a.set(10);
  b.set(20);
  a.set(30);
});
// effect runs only once

`transaction(fn)`

Current semantics:

Identical to batch(fn)
Effects are merged
signal.set() is still synchronous
Reads inside the block see the latest state

At the moment, transaction mainly exists to make experiments and testing clearer.
Later, it can be extended with logging, rollback, or other advanced capabilities.

import { batch } from "./scheduler";

// currently identical to batch; reserved for future upgrades
export function transaction<T>(fn: () => T): T {
  return batch(fn);
}

Example: Effect Runs Only Once

const a = signal(1);
const b = signal(2);

const stop = createEffect(() => {
  console.log("sum =", a.get() + b.get());
});

batch(() => {
  a.set(10);
  b.set(20);
  a.set(30);
});
// logs once: sum = 50

stop();

Example: Interaction with `computed`

const a = signal(1);
const b = signal(2);
const sum = computed(() => a.get() + b.get());

const stop = createEffect(() => {
  console.log("double =", sum.get() * 2);
});

transaction(() => {
  a.set(5);
  b.set(7);

  // Reading inside the transaction:
  // computed recomputes lazily when needed
  console.log("peek in tx =", sum.get() * 2); // 24
});

// microtask:
// effect runs once → "double = 24"

stop();

Batch Timeline

Merging Multiple `set()` Calls

Batch Data Flow

Common Pitfalls

Repeatedly setting the same signal inside a batch

The last write wins
This is expected behavior
If needed, you can deduplicate values before calling set()

Doing heavy synchronous work inside a batch

Microtasks are scheduled only after the batch ends
Long synchronous work delays UI updates

Want to immediately observe effect execution?

Use flushSync() to force an immediate flush

Conclusion

computed controls when values are calculated (lazy evaluation)
batch / transaction control when side effects run (merged at the end)

Once these responsibilities are clearly separated, your reactive system becomes both stable and smooth in practice.

At this point, the system we’ve built is already quite complete.
Experienced readers should be able to see how it can be transplanted into their framework of choice—the core concepts are all here.

In the next article, we’ll try running this system inside a React environment, and discuss some of the limitations imposed by framework-level rendering.

Internal Design Choices for Effects: Implementing Effects (II)

Luciano0322 — Wed, 11 Feb 2026 01:05:25 +0000

Quick Recap

Do you remember this diagram?

In the previous article, we introduced the Registry abstraction, which gives us the flexibility to choose different underlying data structures for Effect scheduling.

One key detail from Part I: schedule() does not run effects immediately—it enqueues them. We flush the queue in a microtask so multiple set() calls in the same tick collapse into a single re-run. This avoids re-entrancy/cascading runs during synchronous writes and makes effect execution more predictable.

At this point, you might be wondering:

Why do we even need a Registry?

Why a Registry Is Necessary

When signal.set() is called, we need to go from an effect node back to its corresponding EffectInstance so that we can invoke schedule().

To achieve this without polluting the public API and while keeping O(1) lookup, we introduced the EffectRegistry abstraction in the previous article:

// registry.ts
import type { Node } from '../graph';

export interface EffectInstanceLike { schedule(): void }

export interface EffectRegistry {
  get(node: Node): EffectInstanceLike | undefined;
  set(node: Node, inst: EffectInstanceLike): void;
  delete(node: Node): void;
}

Callers (both effect and signal) only interact with get / set / delete.
They do not care whether the underlying implementation uses a Symbol, a WeakMap, or something else entirely.

Understanding `WeakMap`

A Simple Comparison

Map
- Iterable
- Has .size
- Keys are strongly referenced (you must delete entries manually)
WeakMap
- Not iterable
- No .size
- Keys are weakly referenced (entries may be removed automatically by GC)

Side-by-Side Comparison

Aspect	Map	WeakMap
Key types	Any (including primitives)	Objects only (Function / Array / DOM / your `Node`)
Iterable	✅ `keys / values / entries / for..of`	❌ Not iterable
`.size`	✅ Yes	❌ No
GC behavior	Strong reference: entry stays until deleted	Weak reference: entry can be GC’d
Typical use	Enumeration, sorting, stats, LRU	Object → side data (cache, state, executors)
Risk	Forgetting `delete` → memory growth	Cannot inspect or count entries

Intuition:
WeakMap is ideal for attaching side data to external objects—without modifying their public structure and without preventing garbage collection.

This matches our exact use case:

Node (effect node) → EffectInstance (executor)

A Quick Example

const wm = new WeakMap();

const o1 = { firstName: "John" };
const o2 = { lastName: "Wick" };
const o3 = { nickName: "papayaga" };

wm.set(o1, o2);
wm.set(o2, o1);

wm.get(o1); // O(1) → { lastName: "Wick" }
wm.get(o2); // O(1) → { firstName: "John" }
wm.get(o3); // undefined

wm.has(o1); // true
wm.has(o2); // true
wm.has(o3); // false

wm.delete(o1);

wm.get(o1); // undefined
wm.get(o2); // O(1) → { firstName: "John" }

Key takeaways:

Only set / get / has / delete
No iteration
No .size

You cannot use WeakMap to list all entries (e.g. for DevTools).
If you need that, maintain a separate list or use Map in development builds only.

Common Pitfalls

WeakMap does not clean up your strong references
- If anywhere still holds a strong reference to the key or value, GC will not reclaim it.
- You should still call delete during dispose().
Key equality is by reference
- You must use the same object instance.
- Re-creating an identical object does not work.

Choosing an Implementation

In our implementation, these are simply two different backends for the same EffectRegistry interface.

Switching requires only changing an import.
The call sites remain unchanged.

Two Registry Implementations

SymbolRegistry (same approach as the previous article)

// registry.ts
export const EffectSlot: unique symbol = Symbol('EffectSlot');

type EffectCarrier = {
  [EffectSlot]?: EffectInstanceLike;
};

export const SymbolRegistry: EffectRegistry = {
  get(n) {
    return (n as EffectCarrier)[EffectSlot];
  },
  set(n, i) {
    Object.defineProperty(n as EffectCarrier, EffectSlot, {
      value: i,
      enumerable: false,
      configurable: true,
    });
  },
  delete(n) {
    Reflect.deleteProperty(n as EffectCarrier, EffectSlot);
  },
};

WeakMapRegistry

// registry.ts
const table = new WeakMap<Node, EffectInstanceLike>();

export const WeakMapRegistry: EffectRegistry = {
  get: (n) => table.get(n),
  set: (n, i) => {
    table.set(n, i);
  },
  delete: (n) => {
    table.delete(n);
  },
};

One-Line Switch at the Call Site

// effect.ts & signal.ts
import { SymbolRegistry } from './registry';
// or
import { WeakMapRegistry } from './registry';

WeakMap vs Symbol: A Comparison

Aspect	SymbolRegistry	WeakMapRegistry
Mental overhead	Low: a private non-enumerable slot	Medium: requires understanding weak references
Modifies `Node`	✅ Adds a private Symbol slot (invisible externally)	❌ Completely external
Iterable / `.size`	Not iterable (private slot)	Not iterable, no `.size`
GC behavior	Tied to node; must delete on `dispose()`	Weak key; GC-friendly, but `delete` still recommended
Call-site typing	Clean (`EffectRegistry` always takes `Node`)	Same
Common risk	Accidentally using different `Symbol` instances	Expecting iteration (impossible); lingering strong refs

So… Which One Should You Use?

If you already understand WeakMap, just use it.
It is the more intuitive choice here.

That said, WeakMap is rarely encountered in day-to-day JavaScript.
I have even seen interviewers who did not know what Map was.

For that reason, I chose to teach using the Symbol-based approach first, and this article mainly serves as an add-on for experienced engineers.

A Note on Using Arrays

Earlier examples sometimes used plain arrays for simplicity.
In real implementations, avoid arrays for graph-based problems.

This is a Graph, not a list:

Map is almost always a better fit than arrays.
Arrays impose lookup costs.
You can work around this—but it requires extra bookkeeping.

Since the Registry abstraction already exists, swapping implementations later is trivial.

Conclusion

At this point, we now have:

Graph construction withObserver automatically builds dependency edges
Notification signal.set() triggers SymbolRegistry.get(sub)?.schedule() or WeakMapRegistry.get(sub)?.schedule()
Lifecycle management onCleanup and dispose()

In the next article, we will implement computed, completing the core mechanics of our signal system.

Making the Graph Actually Move: Implementing effect (Part I)

Luciano0322 — Wed, 04 Feb 2026 02:05:45 +0000

Introduction

In the previous article, we finished a Signal core that supports subscriptions. In this one, we’ll implement Effect, so each dependency can be tracked automatically—turning a previously static graph into a reactive one that truly “moves.”

Goals of this article

createEffect(fn): Run fn inside a tracking scope and automatically collect dependency edges.
signal.set(): Notify dependent effects and re-run them once via microtask batching.
onCleanup(cb) and dispose(): Clean up before re-runs, and allow manual disposal (unsubscribe).

Core class relationships (with the `Registry` abstraction)

Let’s establish the role boundaries with this diagram:

Node: A single node model, distinguished by kind (signal / computed / effect).
EffectInstance: Owns an effect node and is responsible for run / schedule / dispose.
EffectRegistry: An abstraction interface. Both SymbolRegistry and WeakMapRegistry implement it (Part 2 will demonstrate switching).

EffectInstance owns the node (Node). The registry is just a “lookup table” that lets us recover the instance from the node.

The `createEffect` construction flow

This diagram shows construction and the first execution:

Construct an EffectInstance.
Register “node → instance” into the registry.
First run() executes within a tracking scope to collect dependencies (build the graph). Notification is not the focus yet.

Graph building comes before notification. The behavioral core of this article is: effects can re-run. Graph maintenance (collecting and detaching deps) is handled internally in run().

How a signal notifies an effect (via the registry)

This diagram walks through “signal update → re-run” end-to-end:

signal.set() updates the value.
Iterate subs (who subscribed to this signal).
If the subscriber is an effect node, retrieve the corresponding instance from the registry and call schedule().

The registry is only a lookup. The real work happens inside EffectInstance.schedule(), which batches via microtasks and then calls run().

Recap: the base model

Single node + tracking utility

// Previous article model
// graph.ts
export type Kind = 'signal' | 'computed' | 'effect';

export interface Node {
  kind: Kind;
  deps: Set<Node>; // who I depend on (effect / computed)
  subs: Set<Node>; // who depends on me (signal / computed)
}

export function link(from: Node, to: Node) {
  if (from.kind === 'signal') throw new Error('Signal nodes cannot depend on others');
  from.deps.add(to);
  to.subs.add(from);
}

export function unlink(from: Node, to: Node) {
  from.deps.delete(to);
  to.subs.delete(from);
}

// Tracking: reads under an observer context automatically create an edge Observer -> Trackable
let currentObserver: Node | null = null;

export function withObserver<T>(obs: Node, fn: () => T): T {
  const prev = currentObserver;
  currentObserver = obs;
  try {
    return fn();
  } finally {
    currentObserver = prev;
  }
}

export function track(dep: Node) {
  if (!currentObserver) return;
  link(currentObserver, dep);
}

Effect Registry abstraction

In this article we’ll start with a Symbol-based registry (Part 2 will switch to a WeakMap-based version):

// registry.ts
import type { Node } from "./graph.js";

export interface EffectInstanceLike {
  schedule(): void;
}
export const EffectSlot: unique symbol = Symbol("EffectSlot");
export interface EffectCarrier {
  [EffectSlot]?: EffectInstanceLike;
}

export interface EffectRegistry {
  get(node: EffectCarrier): EffectInstanceLike | undefined;
  set(node: EffectCarrier, inst: EffectInstanceLike): void;
  delete(node: EffectCarrier): void;
}

export const SymbolRegistry: EffectRegistry = {
  get(node) {
    return node[EffectSlot];
  },
  set(node, inst) {
    Object.defineProperty(node, EffectSlot, {
      value: inst,
      enumerable: false,
      configurable: true
    });
  },
  delete(node) {
    Reflect.deleteProperty(node, EffectSlot);
  }
};

The registry’s job is to maintain the Node → EffectInstance relationship, so signal.set() can find the effect to re-run in O(1) time.

Effect

Batch scheduling, re-running, and cleanup (depending on the registry abstraction, not a concrete implementation):

// effect.ts
import { unlink, withObserver, type Node } from "./graph.js";
import { SymbolRegistry, type EffectInstanceLike } from "./registry.js";

type Cleanup = () => void;

// Shared helper: execute cleanups in LIFO order and ensure the list is cleared
function drainCleanups(list: Cleanup[], onError?: (err: unknown) => void) {
  // LIFO: run from tail to head
  for (let i = list.length - 1; i >= 0; i--) {
    const cb = list[i];
    try {
      cb();
    } catch (e) {
      onError?.(e);
    }
  }
  list.length = 0;
}

// Microtask batching
const pending = new Set<EffectInstance>();
let scheduled = false;
function schedule(inst: EffectInstance) {
  if (inst.disposed) return;
  pending.add(inst);
  if (!scheduled) {
    scheduled = true;
    queueMicrotask(() => {
      scheduled = false;
      const list = Array.from(pending);
      pending.clear();
      for (const ef of list) ef.run();
    });
  }
}

let activeEffect: EffectInstance | null = null;
export function onCleanup(cb: Cleanup) {
  if (activeEffect) activeEffect.cleanups.push(cb);
}

export class EffectInstance implements EffectInstanceLike {
  node: Node = {
    kind: 'effect',
    deps: new Set(),
    subs: new Set()
  };
  cleanups: Cleanup[] = [];
  disposed = false;

  constructor(private fn: () => void | Cleanup) {
    SymbolRegistry.set(this.node, this); // Only touch the registry
  }

  run() {
    if (this.disposed) return;

    // 1) cleanup from last run
    drainCleanups(this.cleanups);

    // 2) detach old dependencies
    for (const dep of [...this.node.deps]) unlink(this.node, dep);

    // 3) run inside tracking scope to collect new deps; support returning a cleanup
    activeEffect = this;
    try {
      const ret = withObserver(this.node, this.fn);
      if (typeof ret === 'function') this.cleanups.push(ret);
    } finally {
      activeEffect = null;
    }
  }

  schedule() { schedule(this); }

  dispose() {
    if (this.disposed) return;
    this.disposed = true;

    drainCleanups(this.cleanups);
    for (const dep of [...this.node.deps]) unlink(this.node, dep);
    this.node.deps.clear();

    SymbolRegistry.delete(this.node); // Only touch the registry
  }
}

export function createEffect(fn: () => void | Cleanup) {
  const inst = new EffectInstance(fn);
  inst.run(); // Run once first to collect deps
  return () => inst.dispose();
}

Signal

Notify dependent effects inside set():

// signal.ts
import { link, track, unlink, type Node } from "./graph.js";
import { SymbolRegistry } from "./registry.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 & { kind: 'signal'; value: T; equals: Comparator<T> } = {
    kind: 'signal',
    deps: new Set(), // guaranteed empty by link rules
    subs: new Set(),
    value: initial,
    equals,
  };

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

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

    for (const sub of node.subs) {
      if (sub.kind === 'effect') SymbolRegistry.get(sub)?.schedule();
    }
  };

  const subscribe = (observer: Node) => {
    link(observer, node);
    return () => unlink(observer, node);
  };

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

Example usage

import { signal } from './signal';
import { createEffect, onCleanup } from './effect';

const a = signal(1);
const b = signal(2);

const stop = createEffect(() => {
  console.log('sum =', a.get() + b.get());
  onCleanup(() => console.log('cleanup before rerun'));
});

a.set(10); // microtask: cleanup before rerun → sum = 12
b.set(20); // microtask: cleanup before rerun → sum = 30

stop(); // unsubscribe + cleanup

run() flow diagram

Conclusion

With the flow above, we’ve implemented a functional Effect core. There are still a few things worth calling out:

Snapshot trap: const v = a.get(); a.set(10); v is still the old value. If you need the latest value, call get() again.
Batched multiple sets: multiple set() calls in the same tick will re-run the effect only once (microtask batching).
Dependency drift: every re-run unlinks old deps first, then collects new deps via withObserver, preventing the subscription set from growing indefinitely.

I spent a lot of time reproducing the diagrams in this article to make it easier to understand. Once graphs are involved, there are many subtle details to get right.

In the next article, we’ll discuss internal design choices for Effect (Symbol vs WeakMap), review the fundamentals of WeakMap, and try an alternative implementation via WeakMapRegistry.

Building a Minimal Signal API

Luciano0322 — Wed, 28 Jan 2026 00:40:03 +0000

Introduction

This post continues the idea from the end of the previous article: using closures + destructuring assignment to implement a tiny state “storage” mechanism.

Here’s the starting point:

export type Signal<T> = {
  get(): T;
  set(next: T | ((prev: T) => T)): void;
};

export function signal<T>(initial: T): Signal<T> {
  let value = initial;

  const get = () => value;

  const set = (next: T | ((p: T) => T)) => {
    const nxtVal = typeof next === "function" ? (next as (p: T) => T)(value) : next;
    const isEqual = Object.is(value, nxtVal);
    if (!isEqual) value = nxtVal;
  };

  return { get, set };
}

Remember this diagram?

We’re still missing one crucial piece: a place to store dependencies—namely, the Observers. That’s the last puzzle piece needed to make a Signal “reactive”.

Tracking vs Observing

Let’s clarify terminology first:

Tracking / Trackable : the “source” of information — the thing that can be tracked / subscribed to. The most obvious example: a Signal.
Observing / Observer: the “subscriber” — the thing that reacts to changes. The most obvious example: an Effect.

With this simple split, we can summarize:

Trackable

A subscribable source (e.g. signal, computed)
Internally maintains: subs: Set<Observer> (who is subscribing to me)

Observer

An observer (e.g. computed, effect)
Internally maintains: deps: Set<Trackable> (who I depend on)

Diagram:

From the source perspective:

From the observer perspective:

This forms a bidirectional graph:

Sources know their subscribers
Subscribers know their sources

Since the rest of the series will optimize around these structures, it helps to be comfortable with basic graph concepts.

TypeScript Types and the Core Model

We can simplify the concept into types like this:

export interface Trackable {
  subs: Set<Observer>;
}

export interface Observer {
  deps: Set<Trackable>;
}

Minimal Dependency Tracking Core

We’ll implement dependency tracking with currentObserver + track.

let currentObserver: Observer | null = null;

export function withObserver<T>(obs: Observer, fn: () => T): T {
  const prev = currentObserver;
  currentObserver = obs;
  try {
    return fn();
  } finally {
    currentObserver = prev;
  }
}

export function track(dep: Trackable) {
  if (!currentObserver) return;
  dep.subs.add(currentObserver);
  currentObserver.deps.add(dep);
}

Key idea:

Any read happening inside the tracking window creates an edge: who read whom.

At this stage, we only build edges.
We do not notify anyone yet. Notification / invalidation (dirtying) will be handled in the next article.

Combine It with the Basic Closure-Based `signal`

Now we merge the tracking mechanism into the original closure-based Signal and get a minimal subscribable implementation.

We’ll introduce a unified Node model for signal / computed / effect:

type Kind = "signal" | "computed" | "effect";

export interface Node {
  kind: Kind;
  deps: Set<Node>; // who I depend on (used by computed/effect)
  subs: Set<Node>; // who depends on me (signal/computed can be subscribed)
}

// Invariant: signal cannot have deps; effect doesn't expose subs
export function link(from: Node, to: Node) {
  if (from.kind === "signal") {
    throw new Error("Signal nodes cannot depend on others");
  }
  from.deps.add(to);
  to.subs.add(from);
}

export function unlink(from: Node, to: Node) {
  from.deps.delete(to);
  to.subs.delete(from);
}

// Tracking tool: while inside an "observer context", reads auto-create edges
// (build graph only, no notification yet)
let currentObserver: Node | null = null;

export function withObserver<T>(obs: Node, fn: () => T): T {
  const prev = currentObserver;
  currentObserver = obs;
  try {
    return fn();
  } finally {
    currentObserver = prev;
  }
}

function track(dep: Node) {
  if (!currentObserver) return; // normal read outside tracking
  link(currentObserver, dep); // Observer -> Trackable
}

// Object return is destructuring-friendly.
// Extract Object.is into equals; next article will use it for notification decisions.
type Comparator<T> = (a: T, b: T) => boolean;
const defaultEquals = Object.is;

export function signal<T>(initial: T, equals: Comparator<T> = defaultEquals) {
  // Single node + private value
  const node: Node & { kind: "signal"; value: T; equals: Comparator<T> } = {
    kind: "signal",
    deps: new Set(), // always empty (enforced by link())
    subs: new Set(),
    value: initial,
    equals,
  };

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

  const set = (next: T | ((prev: T) => T)) => {
    const nxtVal = typeof next === "function" ? (next as (p: T) => T)(node.value) : next;
    if (node.equals(node.value, nxtVal)) return;
    node.value = nxtVal;
    // This post only covers subscription graph building.
    // No dirtying / notification yet — next article continues from here.
  };

  // Imperative subscription (for contrast with declarative tracking)
  // Returns an unsubscribe function.
  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 };
}

Why Provide Both `track` and `subscribe`?

Because they serve different purposes:

track() is declarative dependency tracking: inside a tracking block, whatever you read gets subscribed automatically.
This is what computed / effect will use.
subscribe() is imperative subscription: you can manually attach an Observer to a signal.
This resembles traditional event subscription and is useful for interoperability / bridging to other systems.
peek() is a practical escape hatch:
- convenient for tests
- useful when integrating with external frameworks without creating dependencies

Event Subscription vs Dependency Tracking

Aspect	Event subscription (`subscribe(cb)`)	Dependency tracking (`track/withObserver`)
Goal	Call callbacks immediately when value changes	Build a dataflow graph for later recomputation/scheduling
How edges are created	Manual register/unregister	Automatically tracked during the “read phase”
Best for	I/O, logging, bridging third-party systems	Collecting sources for computed/effect and propagating invalidation
Lifecycle	Managed by the user	Can be managed by computed/effect lifecycle automatically

Closing

At this point, we’ve completed “signal + subscription graph building”:

Inside a tracking block like withObserver(() => a.get()), reads automatically create dependency edges: Observer → Trackable.
This post only builds the graph and triggers no re-execution.

Next article is straightforward: implement effect so the graph actually “moves”.

Planned steps:

Create a kind: "effect" node, and on first run use withObserver to collect dependencies.
When any dependent signal.set() happens, notify the corresponding effects and batch re-runs in a microtask.
Add dispose / onCleanup: before each rerun, remove old dependencies and run cleanup hooks.

How Computed Values Really Work: Lazy Evaluation in a Reactive Graph

Luciano0322 — Thu, 22 Jan 2026 05:29:34 +0000

Recap

Before we continue, let’s quickly review what we already have:

1. `graph.ts`

Node { kind, deps, subs }, link / unlink, withObserver / track
(reused from Implementing Effect (I))

2. `EffectRegistry`

Effects.get / set / delete(node: Node)
(reused from Implementing Effect (II))

3. `signal.ts`

set() iterates over subs, and for effects calls
Effects.get(sub)?.schedule()
(we’ll add a branch for computed below)

What Kind of “Memo” Is This `computed`?

TL;DR

This computed is equivalent to Vue’s computed or Solid’s createMemo not React’s useMemo.

It is a node in the reactive dataflow graph that:

Automatically tracks dependencies
Recomputes lazily (only when read)
Is not bound to any component lifecycle

Comparison Table

Aspect	This article’s `computed` (signals)	Vue `computed`	Solid `createMemo`	React `useMemo`
Dependency declaration	Automatic (read = subscribe)	Automatic	Automatic	Manual deps array
When it computes	Lazy, recompute only when stale and read	Lazy	Lazy	During render
Lifecycle	Independent of components	Tied to instance	Tied to root	Bound to render
Role in dataflow graph	Observer + Trackable (`deps` + `subs`)	Same	Same	Not a reactive node
Suitable for side effects	No	No	No	No

Examples

Vue

const a = ref(1);
const b = ref(2);
const sum = computed(() => a.value + b.value);

Solid

const [a] = createSignal(1);
const [b] = createSignal(2);
const sum = createMemo(() => a() + b());

This Article (signals)

const a = signal(1);
const b = signal(2);
const sum = computed(() => a.get() + b.get()); // auto-tracked, lazy

React (for contrast only)

const [a, setA] = useState(1);
const [b, setB] = useState(2);

// Render-time cache only; not part of the reactive graph
const sum = useMemo(() => a + b, [a, b]);

The computed we’re about to implement is the kind that:

Computes only when read
Caches the result
Has explicit upstream/downstream edges in the graph.

Design Considerations

A computed is both:
- An Observer (it depends on others → has deps)
- And a Trackable (others depend on it → has subs)
Two internal states:
- stale: boolean — dirty flag
- computing: boolean — reentrancy guard (cycle detection)
equals(a, b) — skip cache updates when values are equal (default: Object.is)

Who Depends on Whom?

In the diagram below, arrows mean “I depend on this.”

A computed sits in the middle: it has both upstream and downstream edges.

signal: only depended on (no deps)
effect: only depends on others (no subs)
computed: both sides

Push vs Pull: From `set()` to Recompute

signal.set() only pushes invalidation:
- marks computed as stale,
- schedules effects via the registry.
Actual computation happens later, when computed.get() is called.

Key points:

EffectRegistry: maps Node → EffectInstance (via Symbol or WeakMap)
Microtask batching: multiple set() calls in the same tick trigger only one effect run.

Lazy Evaluation Flow of `computed.get()`

Only when read do we check stale
If dirty:
- Unlink old dependencies
- Recompute inside a tracking context
- Cache the result

Push Invalidation, Pull Computation

Push

signal.set()
→ mark computed as stale
→ schedule effects

Pull

computed.get()
→ recompute only if stale

Cycle protection

reading itself while computing throws an error.

Implementing computed

// computed.ts
import { link, unlink, withObserver, track, type Node } from "./graph";
import { SymbolRegistry as Effects } from "./registry";

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

/** Used by signal.set() and other computed nodes to mark dirty */
export function markStale(node: Node) {
  if (node.kind !== "computed") return;
  const c = node as Node & { stale: boolean };
  if (c.stale) return; // already dirty
  c.stale = true;

  // Propagate downstream
  for (const sub of node.subs) {
    if (sub.kind === "computed") {
      markStale(sub); // cascade to downstream computed nodes
    } else if (sub.kind === "effect") {
      Effects.get(sub)?.schedule(); // enqueue effect
    }
  }
}

export function computed<T>(
  fn: () => T,
  equals: Comparator<T> = defaultEquals
) {
  const node: Node & {
    kind: "computed";
    value: T;
    stale: boolean;
    equals: Comparator<T>;
    computing: boolean;
    hasValue: boolean;
  } = {
    kind: "computed",
    deps: new Set(),
    subs: new Set(),
    value: undefined as unknown as T,
    stale: true, // compute on first read
    equals,
    computing: false,
    hasValue: false,
  };

  function recompute() {
    if (node.computing) throw new Error("Cycle detected in computed");
    node.computing = true;

    // Remove old dependencies (avoid dependency drift leaks)
    for (const d of [...node.deps]) unlink(node, d);

    // Track new dependencies during execution
    const next = withObserver(node, fn);

    if (!node.hasValue || !node.equals(node.value, next)) {
      node.value = next;
      node.hasValue = true;
    }
    node.stale = false;
    node.computing = false;
  }

  const get = () => {
    track(node); // allow observers to subscribe
    if (node.stale || !node.hasValue) recompute();
    return node.value;
  };

  const peek = () => node.value;

  const dispose = () => {
    // Remove all upstream and downstream links
    for (const d of [...node.deps]) unlink(node, d);
    for (const s of [...node.subs]) unlink(s, node);
    node.deps.clear();
    node.subs.clear();
    node.stale = true;
    node.hasValue = false;
  };

  // peek, dispose, and _node are for testing convenience
  return { get, peek, dispose, _node: node };
}

Wiring `computed` into `signal.set()`

Add a computed branch in the subscription loop:

// signal.ts
import { markStale } from "./computed";

// inside set()
for (const sub of node.subs) {
  if (sub.kind === "effect") {
    Effects.get(sub)?.schedule();
  } else if (sub.kind === "computed") {
    markStale(sub); // mark dirty only, no immediate recompute
  }
}

This gives us:

Push invalidation (dirty marking)
Pull computation (lazy recompute on read)

Effects are scheduled, but real recomputation only happens when computed.get() is called inside the effect callback.

Usage Example

const a = signal(1);
const b = signal(2);

const sum = computed(() => a.get() + b.get());   // 3
const double = computed(() => sum.get() * 2);    // 6

const stop = createEffect(() => {
  console.log("double =", double.get());
  onCleanup(() => console.log("cleanup"));
});

a.set(5); 
// marks sum & double as stale; schedules effect
// microtask: cleanup → "double = 14" (recompute happens here)

stop();

Conclusion

So far, we’ve completed:

signal.set() Push invalidation — mark computed as stale, schedule effects
computed.get() Pull computation — recompute lazily in a tracking context
EffectRegistry Node → EffectInstance lookup (via Symbol or WeakMap)

In the next article, we’ll introduce Batching & Transactions to eliminate unnecessary repeated updates.

Forem: Luciano0322

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

Selector: observing only part of an object

Module-Scoped vs Component-Scoped Computed

Component scope

Module scope

Interoperability with watch / watchEffect

Observing your signals or computed values

Responsibility Boundaries

Data / business logic

UI / DOM logic

Common Pitfalls

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

Reading signal.get() directly in templates or setup

Driving the same data with both Vue refs and signals

When to Use What?

Conclusion

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

Quick Overview

Common Pitfalls

Stale closures: reading outdated values in events or async callbacks

Creating signal / computed instances inside component render

Computed depending on React snapshots (won't update)

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

Misusing .get() during cleanup

Mixing sources leads to inconsistent UI

Key Concepts Recap

Reading values

Building dependencies

Instance lifecycle

Cleanup

Responsibility separation

Conclusion

Core

React Integration

What's Next

Preview of the Next Article

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

Goal of This Article

Data Flow and Responsibility Boundaries

Tearing: Cause and Solution

Two Common Incorrect Patterns

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

The Situation

The Risk

Problematic Example

Solution

1. Bind to component lifecycle using useComputed

2. Containerize with a Provider

Practical Rule

Important Note About computed

Incorrect Example

Correct Example

Alternative: Pure React derivation

Transitions: Consistency and Timing Coordination

Two Safe Strategies

Strategy 1: Always read external snapshots

Strategy 2: Keep transitional values inside React state

A. React state as draft buffer

B. Local signal state

C. Immediate writes but delayed UI

Common Misunderstandings

Suspense: Consistency When Data Is Not Ready

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`

Timer Example (using `createEffect`)

UI Blinking Example (using `useEffect`)

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

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

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

3. `useEffect` Subscription vs `useSyncExternalStore`

The `useSyncExternalStore` Solution

1️⃣ Snapshot Source: `peek()`

2️⃣ Subscription Mechanism: `createEffect`

3️⃣ Avoid `setState` During Initial Render

`useSignalValue`

`useComputed`

`useSignalState`

`useSignalSelector`

Multiple `set()` Calls Are Batched

❌ Subscribing via `useEffect`

❌ Capturing `get()` in a Closure