How to use computed properties in Vue

Computed properties form the backbone of many reactive frameworks by encapsulating dependencies and recalculating values only when those dependencies change. Unlike simple getters, computed properties track the reactive sources they access during their evaluation and automatically update when any of those sources mutate.

At the core, a computed property can be thought of as a function paired with a caching mechanism and dependency tracking system. When invoked, it checks if any of its dependencies have changed since the last call. If not, it returns the cached value immediately, saving expensive recalculations. If dependencies have changed, it recomputes the value and updates the cache.

One can implement a rudimentary computed property in JavaScript by combining dependency tracking and lazy evaluation. Consider this simplified example:

function createComputed(getter) {
  let cachedValue;
  let dirty = true;

  const subscribers = new Set();

  function evaluate() {
    if (dirty) {
      cachedValue = getter();
      dirty = false;
    }
    return cachedValue;
  }

  return {
    get value() {
      // In a real system, that's where dependency collection happens.
      return evaluate();
    },
    // Simulate dependency change notification
    notifyChange() {
      dirty = true;
      subscribers.forEach(fn => fn());
    },
    subscribe(fn) {
      subscribers.add(fn);
    }
  };
}

This snippet abstracts the concept: getter is your computation, dirty flags when recalculation is needed, and cachedValue stores the last computed result. The notifyChange method mimics a dependency update, marking the computed property as dirty, so the next read triggers recalculation.

To make computed properties truly reactive, the system must track which reactive sources the getter accesses. This usually requires a dependency collection phase where reactive getters register themselves as dependencies of the computed property. When a reactive source changes, it informs all its dependents so they can update accordingly.

Let’s extend the previous example by simulating a reactive dependency:

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

  return {
    get value() {
      // Register dependency here in a real system.
      return value;
    },
    set value(newValue) {
      if (newValue !== value) {
        value = newValue;
        subscribers.forEach(fn => fn());
      }
    },
    subscribe(fn) {
      subscribers.add(fn);
    }
  };
}

Now we can create a reactive value and a computed property that depends on it:

const count = createReactive(0);

const doubleCount = createComputed(() => count.value * 2);

// For demonstration, subscribe to changes in doubleCount
doubleCount.subscribe(() => {
  console.log('doubleCount changed:', doubleCount.value);
});

// In a full reactive system, setting count.value would trigger notifications.
count.value = 1;  // doubleCount should now be dirty and recomputed on next access
console.log(doubleCount.value);  // Outputs 2

Notice here that the subscription and notification mechanism is the crux of dependency management. The computed property subscribes to its dependencies, and dependencies notify their subscribers upon change. This chaining allows the system to propagate updates efficiently without redundant calculations.

Most frameworks optimize this further by batching updates and delaying recalculations until values are actually requested, rather than immediately upon dependency change. This lazy evaluation model ensures that computations only happen when necessary, keeping UI updates performant even under heavy state churn.

When you design your own reactive system or try to understand existing ones, keep in mind that computed properties are fundamentally about three things: tracking dependencies, caching results, and efficiently invalidating those caches when sources change. Without any one of these, you lose the performance benefits and correctness guarantees that reactive programming promises.

The trickiest part is often the dependency tracking: how does the computed property know which reactive sources it depends on? A common pattern involves a global “dependency collector” this is enabled during the computed property’s evaluation. When reactive getters run, they check if dependency collection is active and register themselves accordingly. This inversion of control can feel a bit magical but is essential for automatic tracking.

Here’s a simplified sketch of this concept:

let activeCollector = null;

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

  return {
    get value() {
      if (activeCollector) {
        subscribers.add(activeCollector);
      }
      return value;
    },
    set value(newValue) {
      if (newValue !== value) {
        value = newValue;
        subscribers.forEach(fn => fn());
      }
    },
  };
}

function createComputed(getter) {
  let cachedValue;
  let dirty = true;

  function evaluate() {
    if (dirty) {
      activeCollector = () => {
        dirty = true;
      };
      cachedValue = getter();
      activeCollector = null;
      dirty = false;
    }
    return cachedValue;
  }

  return {
    get value() {
      return evaluate();
    }
  };
}

In this model, when getter runs, any reactive getters it calls will add the computed property’s invalidation callback to their subscribers. When those reactive sources update, they invoke the callback, marking the computed property as dirty. This elegant dance is what powers frameworks like Vue and Solid under the hood.

Understanding this mechanism demystifies why computed properties are so powerful and why they avoid unnecessary recalculations, making reactive interfaces snappy and efficient. Without this system, you’d be forced to manually track dependencies or recompute everything on every change, which quickly becomes untenable.

Next up, we’ll dive into how you can leverage these computed properties to build truly reactive programming patterns that respond to state changes automatically and declaratively, freeing you from the tyranny of manual updates and event listeners. But first, internalizing this core dependency and invalidation model is key to writing effective reactive code.

Imagine you want to create a computed property that depends on multiple reactive sources. Each source must notify the computed property when it changes, so the computed property can invalidate its cache. Here is a slightly more complex example:

const a = createReactive(1);
const b = createReactive(2);

const sum = createComputed(() => a.value + b.value);

sum.subscribe(() => {
  console.log('sum updated:', sum.value);
});

a.value = 3;  // triggers sum invalidation
b.value = 5;  // triggers sum invalidation

console.log(sum.value);  // Outputs 8

Notice how the computed property’s value stays consistent with the latest reactive sources, recalculating only when accessed after a change. This lazy recalculation is what keeps applications fast and responsive without sacrificing correctness.

One subtle point is that dependency tracking must be precise: any dependencies accessed during computation should be tracked, but nothing more. Accessing non-reactive values or unrelated state must not register as dependencies, or else you risk unnecessary recalculations or stale data. This precision comes from carefully controlling when dependency collection is active and what is considered reactive.

So the next time you dig into a reactive framework’s computed property, remember that underneath it all lies a finely tuned interplay of dependency collection, caching, and invalidation – a silent but crucial engine that keeps your UI in sync with your data without breaking a sweat. The rest is just polish and developer ergonomics layered on top.

With this foundation, you’re ready to explore how computed properties can be leveraged for declarative, reactive programming that lets you focus on what your app should do, rather than how to keep everything in sync manually. But before that, make sure you’re comfortable with how the mechanics of dependency tracking and cache invalidation work, as they’re the pillars upon which reactive programming stands.

Imagine extending this pattern to nested computed properties, asynchronous dependencies, or batched updates. Each adds complexity but builds on the same fundamental principles, demonstrating the power and flexibility of this approach. The core concept remains: track dependencies when computing, cache results, and invalidate caches on changes.

At the end of the day, computed properties are a simple idea made elegant and efficient by carefully managing dependencies and caching. This subtle machinery is what turns reactive programming from a conceptual model into a practical and powerful tool for building modern applications that react fluidly to changing data.

Moving forward, we’ll look at practical patterns for using computed properties to build reactive data flows, including how to coordinate multiple computed values, handle side effects, and compose reactive logic for complex UIs. But it all rests on this fundamental understanding of how computed properties internally handle dependencies and cache invalidation – the invisible engine of reactivity.

And speaking of engines, the next topic will focus on using computed properties effectively, where you’ll see how this core machinery translates into real-world reactive programming patterns that simplify your code and enhance performance.

But for now, keep this mental model front and center: computed properties are functions with memory that automatically watch their inputs and refresh themselves only when necessary. This balance of laziness and reactivity is their secret sauce, and mastering it will unlock a new level of fluency in reactive programming.

As you build more complex reactive systems, you’ll appreciate how this approach elegantly solves the problem of keeping derived state in sync without manual bookkeeping – a problem that once plagued UI development and still does if you stray outside reactive paradigms.

The next step is to see how these building blocks fit into larger reactive workflows. But before that, take a moment to reflect on the importance of precise dependency tracking and cache invalidation – the mechanisms that turn simple getters into powerful computed properties that drive your application’s reactivity.

Keep experimenting with the provided code snippets, try adding more reactive sources, nesting computed properties, or implementing your own dependency tracking system. There’s no better way to internalize these concepts than by building your own reactive core from scratch.

…

Using computed properties for reactive programming

When you start using computed properties in a reactive programming context, one of the most powerful patterns you encounter is composing multiple computed properties together. This composition enables complex, declarative data flows where each computed property automatically stays in sync with its dependencies, regardless of how nested or intertwined they become.

Consider a scenario where you have several reactive sources and computed properties that depend on each other. Rather than manually wiring updates or callbacks, you simply define each computed property in terms of other reactive values or computed properties, and the system handles dependency propagation.

const firstName = createReactive('John');
const lastName = createReactive('Doe');

const fullName = createComputed(() => firstName.value + ' ' + lastName.value);

const greeting = createComputed(() => 'Hello, ' + fullName.value + '!');

greeting.subscribe(() => {
  console.log(greeting.value);
});

firstName.value = 'Jane';  // Automatically triggers updates down the chain

Here, greeting depends on fullName, which in turn depends on firstName and lastName. Changing firstName invalidates fullName, which invalidates greeting. Yet, none of this requires explicit event handling; the reactive system’s dependency tracking ensures all computed properties update correctly and lazily.

This lazy evaluation means that if you never access greeting.value after changing firstName, the computations won’t run immediately, avoiding wasted work. Only when the value is requested does the system recompute the necessary chain, reflecting the latest state.

Another common pattern is to leverage computed properties to drive side effects declaratively. Instead of manually subscribing to reactive sources and writing imperative update logic, you can create computed properties that encapsulate side-effectful operations, triggered automatically when dependencies change.

function watchComputed(computedProp, effect) {
  let oldValue = computedProp.value;

  computedProp.subscribe(() => {
    const newValue = computedProp.value;
    if (newValue !== oldValue) {
      effect(newValue, oldValue);
      oldValue = newValue;
    }
  });
}

const temperatureC = createReactive(25);
const temperatureF = createComputed(() => temperatureC.value * 9 / 5 + 32);

watchComputed(temperatureF, (newF, oldF) => {
  console.log(Temperature changed from ${oldF}°F to ${newF}°F);
});

temperatureC.value = 30;  // Logs: Temperature changed from 77°F to 86°F

This watchComputed helper listens for changes on a computed property and runs a side effect when the computed value changes. It is a fundamental building block for reactive UIs, which will allow you to declaratively respond to data changes without tangled event listeners.

In more advanced reactive systems, batching updates is essential to prevent redundant recomputations and re-renders. When multiple reactive sources change in quick succession, you want computed properties to update only once after all changes settle, rather than once per change.

A naive implementation might look like this:

function batch(fn) {
  // Simple batch queue and flushing mechanism
  if (batch.active) {
    fn();
  } else {
    batch.active = true;
    try {
      fn();
    } finally {
      batch.flush();
      batch.active = false;
    }
  }
}

batch.queue = new Set();

batch.flush = () => {
  batch.queue.forEach(fn => fn());
  batch.queue.clear();
};
batch.active = false;

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

  return {
    get value() {
      if (activeCollector) {
        subscribers.add(activeCollector);
      }
      return value;
    },
    set value(newValue) {
      if (newValue !== value) {
        value = newValue;
        if (batch.active) {
          subscribers.forEach(fn => batch.queue.add(fn));
        } else {
          subscribers.forEach(fn => fn());
        }
      }
    },
  };
}

With this batching mechanism, multiple reactive updates inside a batch() call queue subscriber callbacks instead of running them immediately. At the end of the batch, all queued callbacks run once. This prevents repeated recomputation of computed properties that depend on multiple reactive sources being updated in quick succession.

Here’s how you might use it:

batch(() => {
  firstName.value = 'Alice';
  lastName.value = 'Smith';
});
// Only one update cycle happens for computed properties depending on firstName and lastName

By controlling when subscriptions run, batching ensures better performance and avoids “thrashing” your reactive system with redundant updates.

Finally, when building reactive logic, it’s often useful to combine computed properties with control flow logic to conditionally compute values or short-circuit computations. Since computed properties are just functions with cache and dependency tracking, you can embed arbitrary logic inside the getter:

const isLoggedIn = createReactive(false);
const userName = createReactive('Guest');

const welcomeMessage = createComputed(() => {
  if (!isLoggedIn.value) {
    return 'Please log in';
  }
  return 'Welcome back, ' + userName.value;
});

welcomeMessage.subscribe(() => {
  console.log(welcomeMessage.value);
});

isLoggedIn.value = true;
userName.value = 'Charlie';
// Logs: Welcome back, Charlie

This flexibility means computed properties don’t just passively mirror reactive sources—they encapsulate the business logic that derives meaningful state from raw data, all while maintaining automatic synchronization.

In essence, computed properties let you write declarative, composable, and efficient reactive code where derived state is always consistent, side effects are managed cleanly, and performance is optimized through lazy evaluation and batching. Mastering these patterns very important to using the full power of reactive programming.