In Chapter 2 we built a primitive that could hold state and announce when it changed. That was the easy half. The hard half — the half that every reactive framework has to solve — is figuring out which effects care about which signals, without making the developer hand-wire every subscription.

This is the chapter where "reactive" stops being a buzzword and starts being automatic. By the end you'll have a thirty-line module that powers everything else in the framework.

01The problem with manual subscriptions

Here's the naive version of reactivity — and most early frameworks shipped exactly this:

const count = createSignal(0)

// manually subscribe an effect
count.subscribe(() => {
  document.body.textContent = `Count is ${count()}`
})

count.set(1) // → "Count is 1"

That works. For one signal. For one effect. And only as long as you remember to call subscribe in exactly the right place.

The moment you compose three signals into a derived value, the model breaks down. Which signal should you subscribe to — the derived one, or the underlying primitives? Both? What if the derived computation is expensive — do you re-run it on every change, or memoize?

The honest answer: you shouldn't have to think about this at all. The framework should observe what your effect reads and wire up subscriptions automatically.

02A running-effect stack

The trick is older than JavaScript: maintain a stack of currently-executing effects. When a signal is read, it checks "is there an effect running right now?" — and if so, registers itself as a dependency of that effect.

Three pieces, in order:

• A stack — a list of effects currently executing. Push on entry, pop on exit.
• A read hook — every signal's getter peeks at the stack and adds itself to whichever effect is on top.
• A cleanup pass — before re-running an effect, unsubscribe it from all its previous dependencies. Otherwise, branching reads accumulate stale subscriptions.

That's the whole mechanism. Everything else — batching, scheduling, memoization — is an optimization on top.

Let's see it working. Edit the code below and watch the output update as you type.

03Hands-on: build your own signal

This playground is live. Edit the JavaScript and the output panel updates on every keystroke. Try changing the initial value, adding a new signal, or composing two signals together.

If everything's wired up, clicking Increment bumps the count and the DOM updates without you ever writing addEventListener or calling render(). The effect re-ran because it read count() during its first execution — that read registered it as a dependent.

Try this: rename the variable and watch the effect not re-run when name changes but count doesn't appear in the effect body. The dependency graph is precise, not coarse.

04Before & after: auto-tracking

Here's the same logic, written two ways. The "before" version is what most tutorials teach. The "after" version is what production frameworks actually ship. Click the toggle to watch the transition.

// BEFORE — every subscription is manual

const count = createSignal(0);

// developer must remember to subscribe
count.subscribe(() => {
  document.body.textContent = `Count: ${count()}`;
});

// adding a derived value means more wiring
const doubled = createSignal(0);
count.subscribe(() => doubled.set(count() * 2));

// and another subscription for the UI
doubled.subscribe(() => {
  document.title = `Doubled: ${doubled()}`;
});

count.set(5);
// → body updates, doubled updates, title updates
// but you wrote 3 subscribe calls. scale that to 50 signals.

// AFTER — effects auto-track their dependencies

const [count, setCount] = createSignal(0);

// the framework figures out what to subscribe to
createEffect(() => {
  document.body.textContent = `Count: ${count()}`;
});

// derived values compose without wiring
createEffect(() => {
  document.title = `Doubled: ${count() * 2}`;
});

setCount(5);
// → both effects re-run automatically
// dependency tracking is precise: only what you read,
// only when it actually changed. zero subscribe() calls.

The behavioral difference is subtle but profound. The "after" version isn't just shorter — it's correct by construction. There's no way to forget a subscription, no way to subscribe to the wrong signal, no way to leak a subscription you no longer need.

05Common pitfalls

Now that you've seen the mechanism, here are the three ways it bites back:

1. Reading a signal outside an effect

If you call count() in event handler code that runs outside an effect, no subscription is registered. That's correct — but it confuses people who expect "any read anywhere" to be reactive. Reads are only tracked inside effects.

2. Conditional reads

If your effect reads a() on the first run and b() on the second, the subscription set changes between runs. The cleanup-before-rerun pattern handles this — but only if you implement it. Skip the cleanup and you've built a memory leak.

3. Synchronous write loops

Writing to a signal inside an effect that reads it creates an infinite loop. Production frameworks add cycle detection; we'll do that in Chapter 5.

06Wrap up

You now have, in about thirty lines, the same reactivity model that powers SolidJS, Preact Signals, and Vue's ref/effect pair. The names are different, the optimizations are wilder, but the core idea — a running-effect stack — is identical.

In Chapter 4 we'll leave the signal layer and move to the DOM. We need a way to describe what the UI should look like, then diff that against what's there. That's the virtual DOM — and despite the name, there's nothing virtual about how real it is.

Continue to Chapter 4 when you're ready. Or scroll back to the prerequisite map and trace where this chapter sits in the larger plan.