DEV Community: Luciano0322

New article published: Building Reactive DevTools A reactive system should not be a black box. In this article, I explore how to make a signal-based runtime observable through node inspection, graph visualization, render counters, and hotspot tracking.

Luciano0322 — Mon, 01 Jun 2026 06:06:33 +0000

Luciano0322

Jun 1

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

#javascript #webdev #frontend #devtool

Comments

5 min read

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Luciano0322 — Mon, 01 Jun 2026 05:59:47 +0000

Recap

In the previous chapters, we explored:

Scheduler internals
Memory and graph management
Priority and layered scheduling
Time-slicing and cooperative scheduling

All of these mechanisms are essential for making a reactivity system work correctly internally.

But internal correctness alone is not enough.

For developers, the more important question is:

How do we observe, debug, and understand the system?

That is where DevTools and diagnostics become critical.

Inspecting Nodes

Why do we need `inspect()`?

One of the most common debugging needs during development is:

“What is the current value of this signal or computed?”

If the only solution is console.log, debugging quickly becomes inconvenient and intrusive.

A proper inspection layer gives developers visibility without polluting application logic.

Feature Design

The inspector should provide:

Current value
Dependency relationships (deps / subs)
Whether the node is:
- stale
- disposed

Implementation

// devtools.ts
// type reused from previous graph.ts
import type { Node } from "./graph.js";

// Assign IDs using WeakMap without polluting Node structure
const ids = new WeakMap<Node, string>();
let seq = 0;

function getId(n: Node) {
  let id = ids.get(n);

  if (!id) {
    id = `${n.kind}#${++seq}`;
    ids.set(n, id);
  }

  return id;
}

export type InspectSnapshot = {
  id: string;
  kind: Node["kind"];
  inDegree: number;
  outDegree: number;
  deps: { id: string; kind: Node["kind"] }[];
  subs: { id: string; kind: Node["kind"] }[];
};

// Get a flat snapshot of a single node (non-recursive)
export function inspect(node: Node): InspectSnapshot {
  return {
    id: getId(node),
    kind: node.kind,
    inDegree: node.deps.size,
    outDegree: node.subs.size,
    deps: [...node.deps].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
    subs: [...node.subs].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
  };
}

Debug-Friendly Logging

export function logInspect(node: Node) {
  const snap = inspect(node);

  console.log(
    `[inspect] ${snap.id} (${snap.kind})  in=${snap.inDegree}  out=${snap.outDegree}`
  );

  if (snap.deps.length) {
    console.log("  deps ↑");
    console.table(snap.deps);
  } else {
    console.log("  deps ↑ (none)");
  }

  if (snap.subs.length) {
    console.log("  subs ↓");
    console.table(snap.subs);
  } else {
    console.log("  subs ↓ (none)");
  }
}

This provides a much friendlier debugging experience than raw logging.

Recursive Graph Inspection

When debugging larger dependency chains, inspecting a single node is often not enough.

We can recursively expand the graph while avoiding cycles.

export function inspectRecursive(root: Node, depth = 1) {
  const seen = new Set<Node>();

  type Row = {
    from: string;
    to: string;
    dir: "deps" | "subs";
  };

  const rows: Row[] = [];

  const queue: Array<{
    node: Node;
    dUp: number;
    dDown: number;
  }> = [{
    node: root,
    dUp: depth,
    dDown: depth,
  }];

  seen.add(root);

  while (queue.length) {
    const { node, dUp, dDown } = queue.shift()!;
    const fromId = getId(node);

    if (dUp > 0) {
      for (const dep of node.deps) {
        rows.push({
          from: getId(dep),
          to: fromId,
          dir: "deps",
        });

        if (!seen.has(dep)) {
          seen.add(dep);

          queue.push({
            node: dep,
            dUp: dUp - 1,
            dDown: 0,
          });
        }
      }
    }

    if (dDown > 0) {
      for (const sub of node.subs) {
        rows.push({
          from: fromId,
          to: getId(sub),
          dir: "subs",
        });

        if (!seen.has(sub)) {
          seen.add(sub);

          queue.push({
            node: sub,
            dUp: 0,
            dDown: dDown - 1,
          });
        }
      }
    }
  }

  return {
    center: getId(root),
    nodes: [...seen].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
    edges: rows,
  };
}

Mermaid Export

We can even export subgraphs into Mermaid diagrams for documentation or DevTools visualization.

export function toMermaid(root: Node, depth = 1) {
  const g = inspectRecursive(root, depth);

  const lines = ["graph TD"];

  for (const n of g.nodes) {
    lines.push(
      `  ${n.id.replace(/[^a-zA-Z0-9_#]/g, "_")}["${n.id}"]`
    );
  }

  for (const e of g.edges) {
    const a = e.from.replace(/[^a-zA-Z0-9_#]/g, "_");
    const b = e.to.replace(/[^a-zA-Z0-9_#]/g, "_");

    lines.push(`  ${a} --> ${b}`);
  }

  return lines.join("\n");
}

API Summary

inspect(node)
- Fastest single-node snapshot
logInspect(node)
- Debug-friendly console tables
inspectRecursive(node, depth)
- Small graph expansion without infinite loops
toMermaid(node, depth)
- Export subgraphs for docs or DevTools rendering

Graph Visualization

As applications grow larger, textual inspection is no longer sufficient.

At that point, we need dependency graph visualization.

Signal nodes (blue) represent data sources
Computed nodes (green) represent derived values
Effect nodes (yellow) represent side effects

Inside DevTools, we could:

Click nodes to inspect current values
Highlight stale nodes
Visualize link/unlink operations
Observe automatic cleanup and graph pruning

This makes the dataflow fully observable.

Instead of a black box, developers can literally see:

Which state triggered which update.

Render Counters

The Problem

In UI frameworks, one of the most common performance issues is over-rendering.

For example:

Components re-render repeatedly
But nothing meaningful actually changes

Feature Design

A render counter can:

Increment on each render
Display a small overlay badge
Aggregate render statistics in DevTools

Why This Matters

This helps developers identify:

Unnecessary re-renders
Missing memoization
Poor equality strategies
Expensive recomputation chains

It also guides optimization decisions like:

memo
shallowEqual
computed caching

Hotspot Tracking

Why Track Hotspots?

In large applications, knowing that something updated is not enough.

We also need to know:

Which nodes update the most frequently?

That is where hotspot profiling becomes valuable.

Feature Design

We can track:

Update counts
Update frequency
Execution duration
Graph degree statistics

And combine them with:

Heatmaps
Timeline views
Priority scheduling traces

Hotspot Implementation

1. `hotspot.ts`

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

export type HotspotStats = {
  updates: number;
  lastTs: number;
  freqPerMin: number;
  durTotal: number;
  durCount: number;
};

let stats = new WeakMap<Node, HotspotStats>();

const liveNodes = new Set<Node>();

const alpha = 0.2;

const now = () =>
  globalThis.performance?.now?.() ?? Date.now();

The system tracks:

Frequency
Total execution time
Average execution time
Update counts

without modifying the core graph structure itself.

2. Tracking Signal Writes

recordUpdate(node);

We only inject instrumentation where actual work happens.

For example:

signal.set()
computed.recompute()
effect.run()

This keeps the core runtime clean and minimally invasive.

3. Wrapping Computation Timing

withTiming(node, () => {
  // recompute logic
});

This allows us to measure:

recomputation frequency
average execution duration
expensive reactive chains

Example Usage

logTopHotspots(5, "freq", allNodes());

logTopHotspots(5, "avgTime", allNodes());

logTopHotspots(5, "updates", allNodes());

This lets us quickly identify:

high-frequency nodes
expensive computations
reactive bottlenecks

Real-World Use Cases

Game Loops

Identify states updating every frame.

Forms

Detect extremely hot input fields.

Data Visualization

Locate nodes responsible for expensive re-renders.

Async Systems

Observe retry storms or invalidation cascades.

Why DevTools Matter

DevTools are not just debugging utilities.

They also help developers:

Build Mental Models

Understand how the reactive graph actually flows.

Optimize Performance

Locate bottlenecks quickly instead of guessing blindly.

Learn Reactivity

Make invisible runtime behavior visible and intuitive.

Possible Future Directions

Timeline Profiling

Visualize update propagation over time.

Priority-Aware Diagnostics

Inspect how different scheduler priorities interact.

Automated Suggestions

Examples:

“This signal updates too frequently.”
“Consider memoizing this computed.”
“This effect causes excessive downstream invalidation.”

Final Thoughts

By adding:

node inspection
graph visualization
render counters
hotspot profiling

we transform the reactive system from a black box into an observable runtime.

This not only improves debugging and optimization,
but also helps developers truly understand how reactivity works internally.

DevTools are not just developer conveniences —
they are part of how a runtime teaches its own architecture.

At this point, I’ve shared most of the core knowledge I gained while implementing this series.

There are still many unexplored trade-offs and architectural differences across reactive libraries, and those differences often determine why certain libraries perform better in specific scenarios.

In the next article, I’d like to share some personal reflections and lessons learned from writing this entire series.

I published a new article in my Signals series. In this article, I explore how cooperative scheduling, shouldYield(), and task chunking help avoid blocking the JavaScript main thread.

Luciano0322 — Tue, 26 May 2026 03:17:32 +0000

Luciano0322

May 26

How React-Style Time-Slicing Keeps UIs Responsive

#javascript #webdev #frontend #typescript

Comments

2 min read

How React-Style Time-Slicing Keeps UIs Responsive

Luciano0322 — Tue, 26 May 2026 03:11:13 +0000

Quick Recap

In the previous article, we introduced priority-based and layered schedulers, solving the problem of “which tasks should run first.”

However, real-world applications introduce another challenge:
long-running tasks can still block the main thread.

To keep applications responsive, a scheduler must also support:

Time-Slicing
Cooperative Scheduling

The Problem: Long Tasks Blocking the Main Thread

Imagine this scenario:

The UI thread is executing a large rendering task — for example, updating 5000 list items at once.

That operation might take tens of milliseconds, or even exceed 100ms before finishing.

During that time:

Mouse movement and keyboard input cannot respond immediately
The UI may freeze and drop below 60 FPS
Users experience visible stuttering and lag

Priority alone is not enough.

Even if a task has the correct priority, once execution begins, it can still monopolize the main thread.

Time-Slicing

The core idea behind Time-Slicing is:

Split a long task into smaller chunks and periodically yield control back to the main thread.

Workflow

A task is divided into smaller chunks
After each chunk, the scheduler checks whether there is remaining execution time
If not → pause execution and continue later during the next available frame or idle period

This ensures:

User input and animations remain responsive
Background work completes progressively over time

Cooperative Scheduling

In operating systems, there are two major scheduling models:

Preemptive Scheduling
Cooperative Scheduling

In JavaScript’s single-threaded environment, true preemption is impossible.

So frameworks adopt cooperative scheduling instead:

Tasks voluntarily check whether they should yield (shouldYield())
If interrupted, the remaining work is re-queued for later execution

This is essentially the strategy used by React Concurrent Mode.

Example Implementation

Here is a simplified example of a Time-Slicing + Cooperative Scheduler:

let deadline = 0;

function shouldYield() {
  return performance.now() >= deadline;
}

export function runWithTimeSlicing<T>(
  work: () => T,
  timeSlice = 5
): T | void {
  deadline = performance.now() + timeSlice;

  while (!shouldYield()) {
    const result = work();
    return result;
  }

  // Not finished → continue later
  queueMicrotask(() =>
    runWithTimeSlicing(work, timeSlice)
  );
}

Key Idea

Each execution is allowed to run for only timeSlice milliseconds
Once the budget is exceeded, control returns to the browser

This prevents long-running tasks from blocking the main thread entirely.

Combining Time-Slicing with Priorities

On top of a layered priority scheduler, we can integrate Time-Slicing strategies:

Immediate / High Priority
- Execute immediately without slicing
Normal Priority
- Use time-slicing and process incrementally
Low / Idle Priority
- Use requestIdleCallback
- Run only when the browser is idle

This allows the system to balance:

Real-time interactions
Heavy background updates
Overall UI smoothness

Time-Slicing Scheduler Flow

Final Thoughts

Priority scheduling solves the question of:

“Which task should run first?”

Time-Slicing and Cooperative Scheduling solve another equally important problem:

“How do we avoid blocking the UI?”

Together, these techniques allow systems such as Signals, React, and Vue to remain responsive even under massive update workloads.

In the next article, we’ll explore DevTools and Diagnostics, including:

Inspecting reactive nodes
Dependency graph visualization
Render counters
Hotspot tracing
Scheduler debugging tools

These tools help us better understand how signals and schedulers behave in real-world applications.

In my latest signal article, I explore how priority queues and layered execution can help a scheduler preserve interaction responsiveness while still maximizing performance utilization.

Luciano0322 — Thu, 21 May 2026 05:22:37 +0000

Luciano0322

May 21

Building a Smarter Scheduler: Priority Queues and Layered Execution

#webdev #javascript #frontend #typescript

Comments

3 min read

Building a Smarter Scheduler: Priority Queues and Layered Execution

Luciano0322 — Thu, 21 May 2026 05:19:07 +0000

Recap

In the previous article, we explored the relationship between the Scheduler and the dependency Graph, and discussed the challenges of memory management and dependency management.

However, in real-world applications, not all tasks have the same level of urgency:

Some updates must take effect immediately, such as text input from the user.
Some updates can be deferred, such as animations or low-priority UI updates.

This is where Priority and Layered Scheduling become important.

Why Do We Need Priority?

Imagine this scenario: a user is typing into an input field through input.onChange, while a large background computation is also running, such as a chart re-render.

If both tasks are placed into the same queue without any priority control, the user input may get blocked, leading to a poor user experience.

The solution: allow high-priority tasks, such as input events, to be processed first, while lower-priority tasks are deferred.

Common Priority Levels

In modern frontend frameworks, scheduling systems usually define priority levels similar to the following:

Immediate / Sync
- Examples: text updates in an input field, urgent error messages
- These must respond immediately and should not be delayed.
High Priority
- Main UI interactions, such as state updates triggered by button clicks.
Normal Priority
- Most non-critical UI updates.
Low Priority / Idle
- Background computation, performance statistics, prefetching, and other non-urgent work.

This ensures that the most important interactions for user experience are always handled first.

Layered Scheduling

Besides priority, another important concept is layering.

We can divide tasks into different layers, where each layer has its own queue, and the Scheduler coordinates the execution between them:

Computation Layer
- Signal / Computed updates
UI Layer
- DOM updates, Virtual DOM diffing
I/O Layer
- Fetch requests, network operations, storage access
Idle Layer
- Non-essential background tasks, such as log collection

This design is somewhat similar to an operating system’s CPU scheduler: different types of tasks are managed separately to prevent them from interfering with each other.

Example Architecture

Here is a simplified version of a Scheduler that supports both priority and layering:

type Priority = "immediate" | "high" | "normal" | "low";

interface Job {
  run(): void;
  priority: Priority;
  layer: "compute" | "ui" | "io" | "idle";
}

const queues: Record<Priority, Job[]> = {
  immediate: [],
  high: [],
  normal: [],
  low: [],
};

export function scheduleJob(job: Job) {
  queues[job.priority].push(job);
  requestFlush();
}

function requestFlush() {
  queueMicrotask(flushJobs);
}

function flushJobs() {
  // Execute jobs by priority
  runQueue(queues.immediate);
  runQueue(queues.high);
  runQueue(queues.normal);
  runQueue(queues.low);
}

function runQueue(queue: Job[]) {
  while (queue.length > 0) {
    const job = queue.shift()!;
    job.run();
  }
}

This is a “single-level priority” example.
If we want to introduce real layering, we can further split queues based on Job.layer.

Understanding the Execution Flow Through a Diagram

Performance and Optimization Strategies

Batching
- Tasks with the same priority can be merged to avoid duplicated computation.
Time-Slicing
- Long-running tasks can be split into smaller chunks to avoid blocking the main thread.
- React Concurrent Mode uses this kind of strategy.
Waterfall Execution
- Run high-priority tasks first, then process lower-priority tasks if there is still enough time.
- If time is insufficient, low-priority tasks can be deferred to the next tick.

Conclusion

Moving from a single queue to a Scheduler with priority and layering has one major goal:

Preserve interaction responsiveness while maximizing performance utilization.

This is why React introduced Concurrent Features, Vue uses a job queue, and signal-based systems are also starting to design more refined scheduling mechanisms.

In the next article, we will dive deeper into Time-Slicing and Cooperative Scheduling, and explore how a scheduler can keep interactions smooth even when handling expensive tasks.

I published a new article in my Signals series. This one is about the hidden cost of fine-grained reactivity: dangling nodes, stale edges, disposal, auto-unlinking, equality strategies, and why the dependency graph is just as important as the Scheduler.

Luciano0322 — Mon, 18 May 2026 08:01:26 +0000

Luciano0322

May 18

Signal Internals: Managing Memory and the Dependency Graph

#javascript #webdev #frontend #typescript

Comments

8 min read

Signal Internals: Managing Memory and the Dependency Graph

Luciano0322 — Mon, 18 May 2026 07:58:45 +0000

Quick Recap

In the previous article, we looked at the role of the Scheduler.

The Scheduler is responsible for arranging downstream jobs after data changes and batching those updates so the system does not recompute everything immediately and repeatedly.

However, scheduling alone is not enough to make a reactive system stable.

If a signal system is expected to run for a long time, especially inside real applications where components mount, unmount, reconnect, and re-track dependencies, two topics become unavoidable:

memory management
dependency graph management

This article focuses on these two layers.

Why Do We Need a Graph?

In a fine-grained reactivity system, the relationships between signal, computed, and effect are essentially a directed graph.

Nodes

A node represents a reactive unit in the system.

Signal: the source of state
Computed: a derived value calculated from other nodes
Effect: a side-effect node, such as DOM updates, logging, or external synchronization

Edges

An edge represents a dependency relationship.

When an effect reads a signal, or when a computed reads another computed, the system creates an edge between the dependent node and the dependency it read.

This gives the runtime a structured way to answer one important question:

When this value changes, who needs to know?

This design serves two major purposes.

1. Precise Updates

When a signal changes, the runtime does not need to notify the entire world.

It only follows the graph edges and finds the nodes that are actually affected.

2. Avoiding Redundant Computation

The graph allows the system to track which computations are still valid and which ones have become stale.

Instead of recomputing everything eagerly, the runtime can mark affected nodes as dirty and only recompute them when necessary.

Without a graph, the Scheduler would be forced to use a broad broadcast mechanism. Every update would become much more expensive because the system would lose the ability to know what is actually related to what.

The Memory Management Problem

Once we introduce a graph, we also introduce ownership and lifetime problems.

A graph is not just a set of values. It is a set of references.

If those references are not cleaned up correctly, the system may continue holding onto nodes that should already be gone.

This is where memory management becomes part of the core design.

1. Dangling Nodes

A dangling node appears when an effect or computed is no longer needed, but its node is still retained by the graph.

This commonly happens when:

a React component unmounts
a Vue component is destroyed
a manually created effect is no longer used
a derived computation becomes unreachable

If the corresponding graph node is not cleaned up, it may continue to be referenced by upstream nodes.

That means the runtime may still keep it alive, even though the application no longer needs it.

This is a typical source of memory leaks in reactive systems.

The solution is straightforward in principle:

When a node is disposed, unlink all of its upstream dependencies.

Disposal is not only about stopping future execution. It is also about removing the node from the graph so it can be released.

2. Stale Edges

A stale edge appears when a node's dependency relationship changes, but the old edge remains in the graph.

For example:

const value = computed(() => {
  if (enabled.get()) {
    return sourceA.get();
  }

  return sourceB.get();
});

When enabled is true, this computed value depends on sourceA.

When enabled becomes false, it should stop depending on sourceA and start depending on sourceB instead.

If the old edge to sourceA is not removed, then future updates to sourceA may still mark this computed value as stale, even though it no longer reads from sourceA.

That is not only inefficient. It also means the graph no longer reflects the real dependency structure of the program.

The solution is to rebuild dependency edges during the tracking phase.

In practice, this usually means:

collect dependencies while executing the tracked function
compare the new dependencies with the old ones
remove edges that are no longer used
add edges that are newly discovered

This is why a signal system needs explicit link and unlink operations.

3. GC and Retain Cycles

JavaScript's garbage collector can handle many circular references.

However, that does not mean a reactive runtime can ignore reference ownership.

If the internal graph structure keeps strong references to nodes that are no longer reachable from user code, those nodes may still remain alive.

The problem is not simply that a cycle exists.

The real problem is that the runtime may accidentally become the owner of objects that should have been released.

There are several ways to reduce this risk:

avoid unnecessary bidirectional ownership
make disposal explicit where lifecycle boundaries are clear
use WeakMap for metadata lookup when the runtime should not own the object
consider WeakRef only when the use case truly requires weak object references

In my own design preference, I would start with explicit disposal first.

It makes lifecycle boundaries easier to reason about. Weak references can be useful, but they should not become a replacement for a clear ownership model.

A Minimal Graph Structure

In a signal system, there is usually a dedicated Graph Layer responsible for managing nodes, dependencies, subscribers, and disposal.

A simplified node structure may look like this:

export interface Node {
  deps?: Set<Node>; // upstream dependencies
  subs?: Set<Node>; // downstream subscribers
  stale?: boolean; // whether the node is dirty
  disposed?: boolean; // whether the node has been released
}

Different libraries may use different names or organize the structure differently, but the underlying idea is usually similar.

If you read through the source code of several reactive libraries, you will often find the same core concepts under different abstractions.

Linking and Unlinking

When a reactive node reads another node during tracking, the runtime creates an edge.

A minimal implementation may look like this:

export function link(source: Node, target: Node) {
  (source.deps ??= new Set()).add(target);
  (target.subs ??= new Set()).add(source);
}

export function unlink(source: Node, target: Node) {
  source.deps?.delete(target);
  target.subs?.delete(source);
}

Here, source is the dependent node, and target is the node it depends on.

So the relationship is stored in two directions:

source.deps points to upstream dependencies
target.subs points to downstream subscribers

This bidirectional structure makes propagation efficient, but it also means cleanup must be handled carefully.

Disposing a Node

When an effect is destroyed, the runtime must remove it from its upstream dependencies.

A simplified disposal function may look like this:

export function dispose(node: Node) {
  if (node.deps) {
    for (const dep of node.deps) {
      dep.subs?.delete(node);
    }
  }

  node.deps?.clear();
  node.subs?.clear();
  node.disposed = true;
}

This ensures that:

stale dependencies do not remain in the graph
upstream nodes no longer retain the disposed node
memory can be released after a component or effect is destroyed

In other words, dispose() is not just an API for stopping an effect.

It is a graph cleanup operation.

How the Scheduler Uses the Graph

The Scheduler does not work in isolation.

It relies on the graph to know which nodes should be updated after a change.

A typical flow looks like this:

signal.set() updates the value and marks the signal node as stale.
The Scheduler queues affected jobs.
flushJobs() drains the queue.
The runtime follows subs to propagate invalidation downstream.
If some nodes no longer have subscribers, the runtime may auto-unlink or dispose them.

The important point is this:

The Scheduler decides when work should run, but the graph decides where the work should propagate.

Without the graph, scheduling becomes blind.

Without the Scheduler, graph updates can become chaotic and repetitive.

A stable signal runtime needs both.

Optimization Strategies

In small examples, basic graph management may be enough.

But in real applications, the graph may grow, shrink, and change shape constantly.

That is why signal systems usually need additional optimization strategies.

1. Auto-Unlink

In the standard link / unlink flow, a node may eventually lose all of its downstream subscribers.

If that node still keeps its upstream dependencies, invalid edges may remain in the graph for a long time.

This may not immediately cause incorrect behavior, but it can make the graph larger than necessary.

The solution is auto-unlink:

function autoUnlink(node: Node) {
  if (!node.subs || node.subs.size === 0) {
    for (const dep of node.deps ?? []) {
      dep.subs?.delete(node);
    }

    node.deps?.clear();
  }
}

With this approach, when a computed or effect no longer has subscribers, it can clean up its upstream dependencies automatically.

This prevents dangling dependency relationships from staying in the graph.

In the context of React or Vue, this is similar to removing event listeners during unmount.

The goal is the same: release resources when the lifecycle has ended.

2. Equals Strategy and Performance

In the signal.set() flow, we usually perform an equality check before triggering invalidation.

const set = (next: T) => {
  if (!equals(value, next)) {
    value = next;
    markStale(thisNode);
  }
};

This avoids unnecessary updates.

However, equality checking is not free. Different equality strategies have different trade-offs.

`Object.is`

Object.is is usually the default option.

It is native to JavaScript, fast, and predictable.

It works especially well for primitives and reference equality.

The limitation is that objects and arrays are compared by reference. If a new object is created, it will be treated as a new value even if its contents are structurally similar.

Shallow Equal

Shallow equality can be useful for common object-shaped UI state.

It can reduce unnecessary updates when object references change but the top-level fields remain the same.

The trade-off is that shallow comparison has an O(n) cost based on the number of keys or items being compared.

Custom Equal

Custom equality gives users full control.

It can support domain-specific comparison rules, Immutable.js structures, AST nodes, or deep equality.

However, this flexibility also introduces risk.

A poorly designed custom equality function can become more expensive than the update it tries to avoid.

Practical Guidance

For high-frequency updates, such as game loops, pointer tracking, animation, or real-time telemetry, Object.is is usually the safest default.

For form state or regular UI state, shallow equality can be a pragmatic compromise.

For complex domain data, custom equality may be useful, but it should be introduced deliberately.

The key is not to make equality smarter by default.

The key is to choose the cheapest strategy that preserves correctness for the use case.

3. Lazy Disposal

Some systems delay the actual cleanup work instead of disposing nodes immediately.

This is sometimes called lazy disposal.

The benefit is that it can reduce immediate overhead during hot update paths.

The cost is that the runtime now needs another mechanism to decide when deferred cleanup should happen.

Lazy disposal is not automatically better than explicit disposal.

It is a trade-off between immediate cleanup cost and delayed resource retention.

4. Weak References for Dependencies

Some metadata can be stored through WeakMap so the runtime does not accidentally extend the lifetime of user-owned objects.

This is useful when the runtime needs to associate internal metadata with external objects but should not become their owner.

WeakRef can also be used in more advanced cases, but it should be applied carefully.

Weak references can help reduce retention problems, but they also make lifecycle behavior harder to reason about.

For most signal systems, explicit graph cleanup should still be the foundation.

5. Layered Scheduler

Another optimization is to split work into different layers.

For example:

computation layer
UI update layer
I/O layer

Not all jobs have the same urgency.

A derived value recomputation, a DOM update, a network request, and a logging effect should not necessarily be scheduled with the same priority.

Once the runtime can distinguish these layers, the Scheduler can make more precise decisions.

This becomes especially important when the system needs to support larger applications, async resources, streaming updates, or framework adapters.

Conclusion

The Scheduler is not just a mechanism for running jobs later.

A serious signal system also needs to maintain its dependency graph and manage memory correctly.

The graph tells the runtime where changes should propagate.

Memory management ensures that obsolete nodes and edges do not stay alive forever.

Together, these two layers determine whether the system can remain efficient after running for a long time.

This is why implementations like Solid, Vue, and Preact Signals all contain dedicated logic for dependency tracking, graph cleanup, and lifecycle management.

In the next article, we will continue with priority and layered scheduling: how to optimize different kinds of tasks by giving the Scheduler a more structured execution model.

A Scheduler is the hidden commander of a reactivity system. It decides not whether something should run, but when it should run. New article: Building a Signal Scheduler

Luciano0322 — Mon, 11 May 2026 00:36:15 +0000

Luciano0322

May 11

Building a Signal Scheduler: Sync, Batch, Priority, and Lazy Execution

#webdev #javascript #frontend #typescript

Comments

5 min read

Building a Signal Scheduler: Sync, Batch, Priority, and Lazy Execution

Luciano0322 — Mon, 11 May 2026 00:32:29 +0000

Recap

In the previous article on Atomic Transactions, we looked at how transactions can guarantee state consistency.

In this article, we will go one level deeper into the design of the Scheduler. We will discuss the trade-offs behind different scheduling strategies, and map our implementation back to the corresponding paths in the scheduling flowchart.

The Core Concept of a Scheduler

A Scheduler is the “invisible commander” inside a reactivity system.

It decides when update tasks should run.
It directly affects both performance and the developer mental model.

Simply put, the Scheduler is not about whether something should be computed.

It is about when it should be computed.

Categories of Scheduling Strategies

Scheduling strategies can roughly be divided into the following categories.

Synchronous Scheduling

Characteristic: After data is updated, the corresponding side effects run immediately.
Pros: The logic is straightforward. State changes are reflected instantly.
Cons: It can easily lead to excessive computation, especially when multiple updates happen within a short period of time.

Batch Scheduling

Characteristic: Updates within the same tick are merged, and side effects run only once at the end.
Pros: Reduces duplicate computation and improves performance.
Cons: Requires an additional “task buffering” mechanism, which increases mental complexity.

Priority Scheduling

Characteristic: Tasks are ordered by priority. For example:
- Updates related to user input → high priority
- Background data synchronization → low priority
Pros: Prevents low-value updates from blocking high-value interactions.
Cons: The implementation is much more complex because the system needs to track both deadlines and priorities.

Lazy vs. Eager Scheduling

Lazy: Work is performed only when it is actually needed, such as in pull-based reactivity.
Eager: Once an update happens, downstream computation is scheduled or invalidated immediately, such as in push-based reactivity.

This difference affects the overall strategy of a system:

Lazy scheduling is suitable for read-heavy, write-light scenarios.
Eager scheduling is suitable for write-light, read-heavy scenarios.

Scheduler Strategy Comparison Flowchart

This diagram shows the different strategy paths from data update to UI update.

Strategy Comparison Table

Strategy	Trigger Timing	Core Data Flow	Pros	Cost / Risk	Suitable Scenarios	Common Examples
Synchronous Scheduling (Sync)	Runs immediately after `set()`	`write → compute → effect`	Intuitive mental model, easy to debug	Duplicate computation, interaction jitter	Minimal pages, low-frequency updates	Small frameworks, teaching PoCs
Batch Scheduling (Batch)	Flushes once at the end of the same tick/microtask	`write × N → queue → flush`	Reduces re-rendering, good performance	Deferred consistency, requires a queue	Form interactions, outer animation layers	React batched updates, Vue job queue
Priority Scheduling (Priority)	Slices work by deadline / importance	`enqueue(prio) → run until deadline`	Does not block high-value interactions	High complexity, possible starvation	Long lists, concurrent rendering	React Concurrent, `startTransition`
Lazy	Computes only when read	`write → mark-dirty → compute on read`	Low write cost	Delay on first read	Read-heavy, write-light scenarios	Signals `memo` / `computed`
Eager	Marks downstream work immediately on write	`write → mark downstream → flush`	Faster reads, clear invalidation	Higher write cost	Write-light, read-heavy scenarios; strongly consistent UI	Solid / Preact Signals

How Different Frameworks Implement Scheduling

Framework	Scheduling Mode	Strategy
React	Batch + Priority	microtask queue + concurrent rendering
Vue 3	Batch	job queue
Solid	Microtask Batch (Eager)	Each update marks dependencies and flushes in batches
Signals (Preact / Angular)	Push + Lazy	Dependencies are recomputed only when read

As we can see, each framework makes different trade-offs in Scheduler design. These trade-offs directly affect both performance optimization and the developer mental model.

Mapping Atomic Transactions to the Flowchart

In the Atomic Transaction chapter, we had three important scenarios.

1. Success Path: `begin → writes → commit`

Flowchart path: data update → batch scheduling + eager marking → flush → side effects
Strategy: Batch + Eager

2. Failure Path: `begin → writes → rollback`

Flowchart path: data update → not flushed yet → rollback → mark downstream as dirty → recompute only on the next read
Strategy: Eager marking + Lazy recomputation

3. Read Consistency

When reading values during a transaction, there are two possible approaches:

Block cross-transaction reads → only stable values are visible before commit.
Allow reads of temporary values → snapshot isolation is required to avoid exposing half-finished state.

API Mapping

signal.set() → write
markStale(node) → eager marking
track() / link() / unlink() → dependency tracking
queueMicrotask(flush) → batch flush
flush() → topological recomputation + runEffects
rollback() → restore snapshots + mark values as dirty

Implementation Alignment: `atomic()` / `transaction()`

In the previous article, I kept the original transaction() implementation so that it would be easier to compare with earlier examples. However, in practice, the logic of transaction() should actually be replaced by atomic().

From the perspective of the code, the API that has complete transaction semantics is atomic():

Begin: Create a write log and intercept all writes during the transaction.
Commit: Discard the write log and batch flushJobs() at the end of the same tick. This belongs to Batch + Eager.
Rollback: Restore signal values based on the write log, and mark downstream computed values as dirty, ensuring that cached values are not incorrectly reused before the next read or next successful transaction.

The current transaction() is only equivalent to a batch operation. It lacks rollback, so its semantics do not fully match the previous article.

Suggested Adjustments

To make transaction consistent with the previous semantics, I recommend turning it directly into an alias of atomic():

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> {
  return atomic(fn);
}

Add a muted check to scheduleJob() to avoid enqueueing new tasks during rollback:

export function scheduleJob(job: Schedulable) {
  if (job.disposed) return;
  if (muted > 0) return; // Do not enqueue jobs during rollback / muted phase
  queue.add(job);
  if (!scheduled && batchDepth === 0) {
    scheduled = true;
    queueMicrotask(flushJobs);
  }
}

No other parts need to change. This adjustment simply aligns the implementation behavior with the scheduling strategy described above.

Scheduler and the Developer Mental Model

An interesting question is:

Do developers need to know that the Scheduler exists?

In React, developers often need to consider that “state updates are not immediately reflected,” so the mental model must include the concept of batching.

In Solid or Signals-based systems, because computation is fine-grained, developers almost do not feel the scheduling mechanism. They can usually focus only on the data itself.

Therefore, we can summarize it this way:

A Scheduler is not only a performance optimization tool. It is also a design decision for developer experience.

Looking Ahead

More advanced Schedulers may also include:

Idle Scheduling: Use idle time to process non-urgent tasks.
Work Stealing: Distribute tasks across threads or CPU cores in multi-threaded / multi-core environments.
Adaptive Scheduling: Dynamically adjust scheduling behavior based on device performance or user interaction patterns.

These design concepts are very similar to the schedulers in operating systems. The difference is that here, they are applied in the context of frontend reactivity.

Conclusion

In a reactivity system, the Scheduler plays the role of an “invisible commander.”

It not only determines the upper bound of performance, but also shapes the developer mental model.

React chooses priority + batching.
Vue chooses a batched job queue.
Solid chooses fine-grained eager updates.

Behind the trade-offs of different frameworks, they are all answering the same question:

At what moment should we pay the cost of computation in exchange for immediate UI consistency?

In the next article, we will discuss the memory and graph-management challenges that a Scheduler needs to deal with.

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.

DEV Community: Luciano0322

New article published: Building Reactive DevTools A reactive system should not be a black box. In this article, I explore how to make a signal-based runtime observable through node inspection, graph visualization, render counters, and hotspot tracking.

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Recap

Inspecting Nodes

Why do we need inspect()?

Feature Design

Implementation

Debug-Friendly Logging

Recursive Graph Inspection

Mermaid Export

API Summary

Graph Visualization

Render Counters

The Problem

Feature Design

Why This Matters

Hotspot Tracking

Why Track Hotspots?

Feature Design

Hotspot Implementation

1. hotspot.ts

2. Tracking Signal Writes

3. Wrapping Computation Timing

Example Usage

Real-World Use Cases

Game Loops

Forms

Data Visualization

Async Systems

Why DevTools Matter

Build Mental Models

Optimize Performance

Learn Reactivity

Possible Future Directions

Timeline Profiling

Priority-Aware Diagnostics

Automated Suggestions

Final Thoughts

I published a new article in my Signals series. In this article, I explore how cooperative scheduling, shouldYield(), and task chunking help avoid blocking the JavaScript main thread.

How React-Style Time-Slicing Keeps UIs Responsive

How React-Style Time-Slicing Keeps UIs Responsive

Quick Recap

The Problem: Long Tasks Blocking the Main Thread

Time-Slicing

Workflow

Cooperative Scheduling

So frameworks adopt cooperative scheduling instead:

Example Implementation

Key Idea

Combining Time-Slicing with Priorities

Time-Slicing Scheduler Flow

Final Thoughts

In my latest signal article, I explore how priority queues and layered execution can help a scheduler preserve interaction responsiveness while still maximizing performance utilization.

Building a Smarter Scheduler: Priority Queues and Layered Execution

Building a Smarter Scheduler: Priority Queues and Layered Execution

Recap

Why Do We Need Priority?

Common Priority Levels

Layered Scheduling

Example Architecture

Understanding the Execution Flow Through a Diagram

Performance and Optimization Strategies

Conclusion

I published a new article in my Signals series. This one is about the hidden cost of fine-grained reactivity: dangling nodes, stale edges, disposal, auto-unlinking, equality strategies, and why the dependency graph is just as important as the Scheduler.

Signal Internals: Managing Memory and the Dependency Graph

Signal Internals: Managing Memory and the Dependency Graph

Quick Recap

Why Do We Need a Graph?

Nodes

Edges

1. Precise Updates

2. Avoiding Redundant Computation

The Memory Management Problem

1. Dangling Nodes

2. Stale Edges

3. GC and Retain Cycles

A Minimal Graph Structure

Linking and Unlinking

Why do we need `inspect()`?

1. `hotspot.ts`

`Object.is`

1. Success Path: `begin → writes → commit`

2. Failure Path: `begin → writes → rollback`

Implementation Alignment: `atomic()` / `transaction()`

Extending `scheduler.ts`

Adjustments in `signal.ts`