How Vue Tracks Reactivity

Ask ten Vue developers how reactivity works and nine will say "Proxy". The tenth — the one who gets the follow-up question — will describe the two data structures that the Proxy feeds. Here they are, in the simplified shape they take in Vue's @vue/reactivity package:

// target -> Map(key -> Set<ReactiveEffect>)
const targetMap = new WeakMap()

function reactive(obj) {
  return new Proxy(obj, {
    get(target, key, receiver) {
      const res = Reflect.get(target, key, receiver)
      track(target, key)                 // record: someone is reading key
      if (isObject(res)) return reactive(res)   // deep, lazily, cached
      return res
    },
    set(target, key, value, receiver) {
      const ok = Reflect.set(target, key, value, receiver)
      trigger(target, key)               // notify: key changed
      return ok
    }
  })
}

The WeakMap is keyed by the target object — and weakly, which is what lets a discarded state object be garbage-collected along with its entry, instead of the reactivity bookkeeping pinning dead state alive forever. Inside it, a Map is keyed by the property name, and each value is a Set of effects — render effects, watchers, computeds — that last read that exact property. That nesting is the source of Vue's property-level precision: state.name = 'x' notifies only the dep set for 'name', never the one for 'state.age'.

track is the read side:

function track(target, key) {
  if (!activeEffect) return             // plain script reads register NOTHING
  const depsMap = targetMap.get(target) ?? set(targetMap, target, new Map())
  const dep = depsMap.get(key) ?? set(depsMap, key, new Set())
  dep.add(activeEffect)                 // effect becomes a dependent of this key
  activeEffect.deps.push(dep)           // reverse edge — for cleanup on stop
}

Line by line, this explains half the pitfalls chapter. The if (!activeEffect) return guard is why console.log(state.x) in a timer registers nothing — during a plain read there is no active effect, so there is nothing to record. The double edge (dep.add(effect) plus effect.deps.push(dep)) exists so that when an effect stops — a component unmounts, a watchEffect's cleanup runs — Vue can walk back from the effect to every dep that holds it and erase it, preventing a stopped render effect from being woken forever.

Nesting deserves one note because it trips people writing their own mini-implementations: effects form a stack, not a single slot. watchEffect(() => { watchEffect(() => state.a); state.b }) — or a render effect whose component mounts another component — saves the previous activeEffect, installs the new one, and restores on exit (try/finally in the real source). Reads register against whichever effect is innermost, and each dep set ends up with exactly the effects that read its key inside their own run.

The other half of the story — what a set does with those dep sets, and how one write becomes one batched render — lives in the trigger and scheduler, next.

Two implementation choices in the sketch also explain behavior you can observe. Child objects are wrapped through a caching reactive() call, so the same nested object read twice yields the same proxy — identity comparisons inside a component tree stay stable, and repeated wrapping never doubles the trap layers. And because dep sets are keyed by property, a hot key like a shared selection flag costs the same to trigger as an obscure one: the dispatch loop runs over readers, not over the object's size, which is why a huge state object with three watched fields remains cheap to update.

The set trap ends in trigger(target, key), and its job is embarrassingly small once the maps exist — look up the dep set and run its members:

function trigger(target, key) {
  const dep = targetMap.get(target)?.get(key)
  if (!dep) return                       // nobody ever read this key: nothing to do
  dep.forEach(effect => effect.schedule())
}

Two properties of that loop are the payoff of everything before it. Only previous readers are scheduled. If no effect ever read state.discount, setting it walks an empty (or absent) dep set and returns — no listeners are "notified and ignore it"; the notification is the dep set. And scheduling is not running. An effect's schedule for a render effect does not re-render immediately; it hands itself to the job queue:

const queue = []
let flushed = false

function queueJob(job) {
  if (!queue.includes(job)) queue.push(job)   // dedupe: same effect queued once
  if (!flushed) { flushed = true; Promise.then(flushJobs) }
}

function flushJobs() {
  queue.splice(0).forEach(job => job.run())   // synchronous batch, then microtask
  flushed = false
}

That is the mechanism behind the batched-updates behavior you observed from the outside: ten count.value++ in one handler enqueue one render effect (the includes dedupe), the flush happens on a microtask after the handler finishes, and the DOM sees one update with final values. It is also why a watcher callback runs after the change and before the next render — both are jobs on the same queue, ordered by creation, executed once.

An effect itself is a small object: the function to run, its deps for cleanup, and a scheduler slot. A render effect's scheduler is queueJob; a watch with a callback gets a scheduler that calls the callback with old/new values; watchEffect re-runs itself eagerly. computed is the variant with a memory: a dirty flag instead of eager scheduling — the setter path marks it dirty without running anything, and the next read re-evaluates lazily. That combination — lazy recomputation on read, re-triggering of downstream readers on change — is why a computed whose inputs never change costs nothing per render, and it is the thread that continues in computed Basics.

One honest complexity note: the real implementation adds layers the sketch omits — dep sets are trimmed so stopped effects leave nothing behind, triggers batch effects by type (avoiding a child rendering before its parent), scheduler jobs carry an id for insertion order, and pauseTracking/resetTracking guards protect internal reads (like iterating a dep set) from polluting the graph. The sketch is the model you should carry; the layers are refinements of it, not different designs.

A worked micro-example cements the cycle. A render effect runs, reads state.query (the read tracks it in query's dep set), then reads state.results.length (registering in that property's dep set). Bumping state.page triggers only the page dep — the render does not re-run and the browser waits. Changing state.query triggers its dep set — the render effect is queued once, and during its next run the old registrations are cleaned up and re-collected against whatever it reads this time. The graph is rebuilt on every run, which is why conditional reads stay correct: a branch that stops touching a key stops being scheduled by it.

If the whole system is Proxies, why does ref(0) not proxy the zero? Because there is nothing to proxy: new Proxy(0, ...) is a TypeError — Proxies require an object target. The value must live in an object Vue controls, and the interception point moves from your object's properties to Vue's container's one property: value.

class RefImpl {
  constructor(rawValue) {
    this._value = convert(rawValue)      // objects get wrapped in reactive()
    this._rawValue = rawValue
    this.dep = new Set()                 // its own dep set — a ref is one dep
    this.__v_isRef = true
  }
  get value() {
    trackRef(this)                       // activeEffect registers on THIS ref
    return this._value
  }
  set value(newValue) {
    if (!Object.is(newValue, this._rawValue)) {   // the equality gate
      this._rawValue = newValue
      this._value = convert(newValue)    // fresh objects wrapped on assignment
      triggerRef(this)                   // schedule this ref's dependents
    }
  }
}

Read it against the pitfalls you have already met, and each one becomes an inevitability rather than a rule to memorize. The .value you must type in script is this class's property — there is no proxy around the ref to unwrap it for you. The Object.is gate in the setter is why a same-value write is a silent no-op. The convert in both constructor and setter is why user.value = freshObject comes out deeply reactive and why a nested mutation after replacement still triggers. And triggerRef fans out through dep — a ref's dependents are computeds and effects that read its value getter, tracked in the same track/trigger machinery, just with the ref itself (not a target object and key) as the address.

Comparing the two halves of the system makes the design legible:

computed slots into the same picture as a RefImpl subclass with a custom getter: its value access recomputes only when marked dirty, and its own dep set carries the computeds and renders that read it — one more reason the whole system composes: everything reactive is either a proxy feeding targetMap or a container with a dep set, and every effect is just a function with a scheduler.

For interviews, the three-sentence answer to "explain Vue's reactivity" is: reactive wraps objects in a Proxy whose get/set traps record and dispatch through a WeakMap of per-key effect sets; effects — renders, watchers, computeds — register their reads while running and get scheduled (batched, deduped) when a key they read changes; ref extends the same graph to primitives via a container with a tracked getter/setter, because primitives cannot be Proxy targets. Everything else in this topic is evidence that you have actually built that mental model.

One cross-check proves the model end to end: count the moving parts. A proxy handler, two maps, an effect stack, a job queue, and a container class — five pieces — and every debugging rule from the earlier topics is a corollary of one of them. The plain-read guard is the bail-out in track; the silent no-op write is the missing dep in trigger; the .value requirement is the container's accessor; the batching is the queue's dedupe. When the rules feel derivable rather than memorized, the model is in place.