How Signal Systems Manage Memory and Dependency Graphs

Signals are the backbone of modern reactive frameworks, powering everything from state management to UI updates. But their true strength lies not just in reactivity—it’s in how they handle memory and dependencies over time.

When a signal-based system runs for weeks in a production environment, components mount, unmount, and reconnect while computations derive from shifting data sources. Without careful design, two silent killers emerge: memory leaks and stale dependencies. These issues don’t just bloat memory—they can break reactivity entirely if left unchecked.

Why a Directed Graph Powers Reactive Systems

At the core of every signal library is a directed graph that maps relationships between reactive units. This graph isn’t just an abstract model—it’s the backbone of how updates propagate efficiently through an application.

The graph consists of two fundamental elements:

• Nodes: Represent reactive units, which fall into three categories:
• Signals: The source of state, mutable by user code or external events.
• Computed: Derived values that automatically update when dependencies change.
• Effects: Side effects such as rendering the DOM, logging, or synchronizing with external systems.

• Edges: Represent directional dependencies. When an effect reads a signal or a computed value reads another computed, the system records a directed edge from the dependent to the dependency.

This structure answers a critical question: When a signal updates, which nodes actually need to react?

The Two Core Benefits of Graph-Based Reactivity

The directed graph enables two behaviors that separate efficient signal systems from naive ones:

1. Selective Notification: Instead of broadcasting every state change to all parts of the system, the runtime only notifies nodes directly connected in the graph. This prevents unnecessary recomputations and keeps performance predictable even under heavy load.

1. Lazy Recomputation: Nodes aren’t recalculated immediately when a dependency changes. They’re marked as dirty and recomputed only when accessed or when a downstream effect needs their value. This avoids redundant work and reduces CPU usage in long-running applications.

Without this graph structure, the scheduler would default to a broadcast model—where every signal change triggers a full system scan. That approach scales poorly and leads to unpredictable performance.

The Hidden Cost: Memory Leaks in Reactive Graphs

While the graph enables efficient reactivity, it also introduces a new challenge: ownership and lifetime management. The graph isn’t just a data structure—it’s a network of references. When nodes are no longer needed, they must be removed from the graph entirely.

The Problem of Dangling Nodes

A dangling node occurs when a node remains in the graph long after the component or effect that created it has been removed. Common scenarios include:

• A React component unmounting but its cleanup logic failing to remove its effect node.
• A Vue component being destroyed without releasing its computed dependencies.
• A user-created effect persisting even after it’s no longer referenced in the application.

If upstream nodes still hold references to these orphaned nodes, the garbage collector cannot reclaim their memory. This leads to gradual memory inflation and eventual performance degradation.

The fix is simple in theory but critical in practice:

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

Disposal isn’t just about stopping execution—it’s about removing the node from the graph so it can be garbage collected.

Stale Edges: The Silent Reactivity Killer

Consider a computed value that conditionally depends on different signals based on runtime state:

const value = computed(() => {
  return enabled.get() ? sourceA.get() : sourceB.get();
});

When enabled switches from true to false, the dependency on sourceA should be removed and a new one added to sourceB. If the old edge to sourceA remains, future updates to sourceA will still mark value as stale—even though it no longer uses sourceA.

This creates a double problem:

• Unnecessary recomputations: The system wastes cycles recalculating a value that depends on irrelevant signals.
• Incorrect reactivity: The graph no longer reflects the true dependency structure of the program.

The solution requires rebuilding dependency edges during each tracking phase:

• Collect dependencies while executing the tracked function.
• Compare the new set with the existing edges.
• Remove stale edges and add new ones.

This demands explicit link and unlink operations—operations that many libraries overlook until users report memory leaks or stale state bugs.

Garbage Collection and the Trap of Strong References

JavaScript’s garbage collector handles many circular references automatically. But it doesn’t solve the problem of ownership—who controls the lifecycle of each node.

If the runtime holds strong references to nodes that are no longer reachable from user code, those nodes persist indefinitely. This isn’t just a memory issue—it’s a correctness issue.

To mitigate this risk, developers often turn to weak references or WeakMap, but these tools come with trade-offs:

• WeakMap: Useful for metadata lookup when the runtime shouldn’t own the object. Prevents memory leaks but doesn’t help with lifecycle clarity.
• WeakRef: Intended for advanced use cases where weak references are truly necessary, but overuse can obscure ownership boundaries.

The most robust approach remains explicit disposal. It makes lifecycle boundaries visible and predictable, reducing bugs and making memory management auditable.

Building a Minimal Graph Layer

Most signal libraries include a dedicated graph layer responsible for managing nodes, dependencies, and disposal. A minimal node structure might look like this:

export interface Node {
  deps?: Set<Node>;       // Upstream dependencies
  subs?: Set<Node>;       // Downstream subscribers
  stale?: boolean;        // Indicates if the node needs recomputation
  disposed?: boolean;     // Marks the node as released
}

Different libraries may rename fields or use different data structures, but the core concept remains: nodes track their dependencies and dependents, and disposal cleans up both sides of the relationship.

The Future of Signal Memory Management

As reactive systems scale to handle more complex applications—especially in edge environments and long-lived services—the need for robust memory and graph management will only grow. Libraries that prioritize explicit lifecycle control over clever optimization tricks will be the ones that survive production at scale.

The next generation of signal systems won’t just compute values efficiently—they’ll manage memory intentionally. And that could be the difference between a library that works today and one that lasts for years.