Automatic Dependency Tracking

The Magic Question: How Does It Know?

When you write this code:

const firstName = signal('Alice');
const lastName = signal('Smith');

const fullName = computed(() => `${firstName.value} ${lastName.value}`);

How does fullName know it depends on firstName and lastName? You never declared those dependencies. You didn't pass an array like React's useEffect([firstName, lastName]). The system just... knows.

This isn't magic. It's a clever pattern called automatic dependency tracking, and once you understand it, every signal system becomes transparent.

The Mental Model

The Tracking Context Pattern

The core mechanism is a module-scoped variable (often called activeComputation, activeEffect, or currentSubscriber) that points to whatever computation is currently being evaluated.

let activeComputation = null;

function signal(initialValue) {
  let value = initialValue;
  const subscribers = new Set();

  return {
    get value() {
      if (activeComputation) {
        subscribers.add(activeComputation);
        activeComputation.dependencies.add(this);
      }
      return value;
    },
    set value(newValue) {
      if (!Object.is(value, newValue)) {
        value = newValue;
        for (const sub of [...subscribers]) {
          sub.execute();
        }
      }
    }
  };
}

function computed(fn) {
  let cachedValue;
  let dirty = true;

  const computation = {
    dependencies: new Set(),
    execute() {
      dirty = true;
    },
    get value() {
      if (dirty) {
        cleanup(computation);
        const prevComputation = activeComputation;
        activeComputation = computation;
        try {
          cachedValue = fn();
        } finally {
          activeComputation = prevComputation;
        }
        dirty = false;
      }
      if (activeComputation) {
        // This computed is being read inside another tracking context
        // Register as dependency
      }
      return cachedValue;
    }
  };

  return computation;
}

The key lines are:

1. activeComputation = computation -- before running the derivation, we set ourselves as the active context
2. if (activeComputation) subscribers.add(activeComputation) -- when a signal is read, it checks if anyone is tracking
3. activeComputation = prevComputation -- after running, we restore the previous context (supports nesting)

This is a stack. Computeds can nest inside other computeds. The prevComputation save/restore creates an implicit stack.

The Subscription Graph

After all computeds and effects have run once, the system has built a complete subscription graph -- a directed graph where edges represent "depends on" relationships.

const a = signal(1);
const b = signal(2);
const c = computed(() => a.value + b.value);
const d = computed(() => c.value * 2);
const e = computed(() => a.value * 10);

effect(() => console.log(d.value, e.value));

The resulting graph:

a ──→ c ──→ d ──→ effect
 \         ↗
  └──→ e ─┘
b ──→ c

When a changes:

• c is dirty (depends on a)
• d is dirty (depends on c)
• e is dirty (depends on a)
• The effect re-executes (depends on d and e)

When b changes:

• c is dirty (depends on b)
• d is dirty (depends on c)
• e is NOT dirty (doesn't depend on b)
• The effect re-executes, but e returns its cached value

This is automatic. You didn't declare any of these relationships. The tracking context discovered them by running your code.

Cleanup on Re-execution

Here's a subtlety that most tutorials skip: dependencies can change between executions.

const showDetails = signal(false);
const name = signal('Alice');
const bio = signal('Engineer at Google');

const display = computed(() => {
  if (showDetails.value) {
    return `${name.value}: ${bio.value}`;
  }
  return name.value;
});

When showDetails is false, display depends on showDetails and name. When showDetails becomes true, display now also depends on bio.

But here's the critical part: if showDetails was true and becomes false again, display should stop depending on bio. Otherwise, changes to bio would trigger unnecessary recalculations.

The solution: clear all dependencies before each re-execution.

function reexecute(computation) {
  // Remove this computation from all signals' subscriber lists
  for (const dep of computation.dependencies) {
    dep.subscribers.delete(computation);
  }
  computation.dependencies.clear();

  // Re-execute: dependencies will be re-tracked from scratch
  const prevComputation = activeComputation;
  activeComputation = computation;
  try {
    computation.fn();
  } finally {
    activeComputation = prevComputation;
  }
}

Every execution starts with a clean slate. The computation "forgets" all its old dependencies and builds a fresh set by running the function again. This means the dependency graph is always accurate -- it reflects what the computation actually read, not what it might read.

The Diamond Dependency Problem

The diamond problem is the most important consistency challenge in reactive systems. Consider:

const source = signal(1);
const left = computed(() => source.value * 2);
const right = computed(() => source.value + 10);
const bottom = computed(() => left.value + right.value);

effect(() => console.log(bottom.value));

The dependency graph forms a diamond:

     source
    /      \
  left    right
    \      /
     bottom
       |
     effect

When source changes, both left and right are dirty. bottom depends on both. If the system naively propagates notifications:

1. source changes → notifies left and right
2. left recalculates → notifies bottom → bottom recalculates using old right
3. right recalculates → notifies bottom → bottom recalculates again with correct values

That first calculation of bottom at step 2 is a glitch -- it used stale data. And bottom computed twice when it should have computed once.

The solution: topological evaluation

Well-designed signal systems don't eagerly propagate values. Instead:

1. Mark all downstream nodes as dirty (push notification)
2. Collect all dirty nodes
3. Sort by topological order (depth in the graph)
4. Evaluate in order

Batching Updates

What happens when multiple signals change at once?

const x = signal(1);
const y = signal(2);
const sum = computed(() => x.value + y.value);

effect(() => console.log(sum.value));

// Without batching:
x.value = 10;  // effect runs: logs 12
y.value = 20;  // effect runs: logs 30

// With batching:
batch(() => {
  x.value = 10;
  y.value = 20;
});
// effect runs once: logs 30

Without batching, changing x triggers the effect, which sees x=10, y=2 (intermediate state). Then changing y triggers the effect again with x=10, y=20 (final state). Two executions, one of which showed an intermediate state the user never intended.

Batching defers all notifications until the batch completes:

function batch(fn) {
  batchDepth++;
  try {
    fn();
  } finally {
    batchDepth--;
    if (batchDepth === 0) {
      flushPendingNotifications();
    }
  }
}

During a batch, signal writes still update the stored value, but subscriber notifications are queued instead of executed. When the batch ends, all queued notifications flush at once, and the topological evaluation runs on the final state.

Advanced: Dynamic Dependency Graphs

The dependency graph isn't static. It changes on every execution based on code paths taken:

const loggedIn = signal(false);
const userName = signal('');
const guestCount = signal(0);

const greeting = computed(() => {
  if (loggedIn.value) {
    return `Welcome back, ${userName.value}!`;
  }
  return `Guest #${guestCount.value}`;
});

When loggedIn is false:

• greeting depends on loggedIn and guestCount
• Changes to userName do NOT trigger a recalculation

When loggedIn becomes true:

• greeting now depends on loggedIn and userName
• Changes to guestCount do NOT trigger a recalculation

This is fundamentally different from React's useEffect dependency array, which is static. You declare all possible dependencies upfront. Signals discover actual dependencies at runtime. This means:

• No stale closure bugs (signals always read the current value)
• No unnecessary re-executions from listed-but-unread dependencies
• No "exhaustive deps" lint rule needed

const stack = [];

function pushTracking(computation) {
  stack.push(computation);
  activeComputation = computation;
}

function popTracking() {
  stack.pop();
  activeComputation = stack[stack.length - 1] ?? null;
}