Building Reactive Objects

Introduction: From Logging to Reactivity

In our first lesson, we learned how to use the Proxy object and the Reflect API to create a logging tool . We saw how to watch an object and print a message every time someone accessed or changed a property. While logging is a great way to debug your code, we can take this concept much further. The idea of " reactivity " is a core part of modern web development. You might have used frameworks like Vue or libraries that automatically update the screen whenever your data changes. This happens because the system is "reacting" to changes in your data. In this lesson, we are going to build our own reactive state system . Instead of just printing to the console, our proxy will trigger a specific callback function whenever a property is updated or deleted. This allows us to build applications that stay in sync with their data automatically.

The Basic Reactive Proxy Pattern

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Deep Reactivity for Nested Objects

Most real-world data is nested. For example, a user object might have a profile object inside it. If we only wrap the top-level user, changing user.profile.name will not trigger our set trap. This is because when we access user.profile, the proxy returns the original, unwrapped profile object. To fix this, we need "deep reactivity."

We can achieve this by adding a get trap. When a user tries to access a property, we check whether the value being returned is another object. If it is, we wrap that inner object in a proxy as well before returning it.

JavaScript

get(obj, prop) {
  const value = Reflect.get(obj, prop);
  // If the value is an object, wrap it in a proxy before returning
  if (value !== null && typeof value === 'object') {
    return createReactive(value, onChange);
  }
  return value;
}

get(obj, prop) {
  const value = Reflect.get(obj, prop);
  // If the value is an object, wrap it in a proxy before returning
  if (value !== null && typeof value === 'object') {
    return createReactive(value, onChange);
  }
  return value;
}

This creates a chain of proxies so that a set or deleteProperty at any depth will trigger the callback. Keep in mind, though, that our onChange only receives the leaf property name — not the full path to it — so the callback alone cannot tell you where in the nested structure the change occurred. This "on-demand" wrapping is efficient because we only create proxies for the parts of the object that the user actually touches.

One important caveat: the deep-wrapping approach shown here is designed for plain objects and arrays — the kind of data you would write as an object or array literal. Built-in objects such as Date, Map, Set, or class instances rely on internal mechanics (often called internal slots) that can break when accessed through a proxy, because their methods expect this to be the real object rather than a wrapper. DOM nodes have the same problem. A production reactive library adds special checks to skip or specially handle these types. In this lesson we keep the focus on plain objects and arrays so the core pattern stays clear.

Maintaining Referential Integrity with WeakMap

Adding deep reactivity introduces a new problem called "identity discontinuity." If you access state.user twice, our code might create two different proxies for the same user object. This means state.user === state.user would be false, which can break your program and cause unexpected bugs. We need a way to ensure that one object always maps to exactly one proxy.

We solve this by using a WeakMap to cache our proxies. Before creating a new proxy, we check the cache to see whether we have already made one for that specific object. If we have, we return the cached version.

There is a subtlety, though: the correct proxy for an object depends on which onChange it is bound to. If we cached by target alone, the first caller's callback would "win," and a later call wrapping the same object with a different callback would wrongly receive the original proxy. So we scope the cache per callback — one target maps to one proxy for a given onChange.

JavaScript

const proxyCache = new WeakMap();

function createReactive(target, onChange) {
  // Each onChange gets its own target -> proxy cache
  let cache = proxyCache.get(onChange);
  if (!cache) {
    cache = new WeakMap();
    proxyCache.set(onChange, cache);
  }

  // Return the existing proxy if we've already created one for this target
  if (cache.has(target)) {
    return cache.get(target);
  }

  // ... handler logic ...

  const proxy = new Proxy(target, handler);
  cache.set(target, proxy);
  return proxy;
}

const proxyCache = new WeakMap();

function createReactive(target, onChange) {
  // Each onChange gets its own target -> proxy cache
  let cache = proxyCache.get(onChange);
  if (!cache) {
    cache = new WeakMap();
    proxyCache.set(onChange, cache);
  }

  // Return the existing proxy if we've already created one for this target
  if (cache.has(target)) {
    return cache.get(target);
  }

  // ... handler logic ...

  const proxy = new Proxy(target, handler);
  cache.set(target, proxy);
  return proxy;
}

We use WeakMap instead of a regular Map because WeakMap allows the garbage collector to remove objects from memory if they are no longer being used elsewhere. This prevents "memory leaks," which is very important for long-running applications.

Introduction: From Logging to Reactivity

The Basic Reactive Proxy Pattern

Join the 1M+ learners on CodeSignal

Deep Reactivity for Nested Objects

Maintaining Referential Integrity with WeakMap

Respecting Proxy Invariants

Avoiding Common Pitfalls

From One Callback to Many Subscribers

Summary and Practice Preparation