Computed Properties vs Manual Calculations
Should derived state be computed automatically from its inputs, or calculated by hand and stored? One of these is a discipline; the other is a liability waiting for a code review.
The short answer
Computed Properties over Manual Calculations for most cases. Derived data should be derived.
- Pick Computed Properties if your value is purely a function of other state — totals, full names, filtered lists, formatted strings. Let it compute. Cache it if profiling proves you need to, not before
- Pick Manual Calculations if the computation is genuinely expensive AND the inputs change far more often than the output is read, or the 'derived' value must be frozen at a point in time (an invoice total at purchase, an audit snapshot). Then store it deliberately and document why
- Also consider: The real question is never 'compute vs store' — it's 'is this value derived or is it a fact?' A fact gets persisted. Derived data gets computed. People reach for manual calculation because computing felt slow once in 2014.
— Nice Pick, opinionated tool recommendations
What they actually are
A computed property is a value defined by a formula over other state — you declare the relationship once and the system recomputes on access. Think Vue/MobX computeds, Swift computed vars, SQL generated columns, a Python @property. A manual calculation is you running the same arithmetic at every call site and either passing the result around or stuffing it into a stored field you now have to maintain. The distinction isn't syntactic sugar. Computed properties encode the dependency graph: change an input, the output is correct by construction. Manual calculations encode nothing — they're a snapshot of a relationship that lives only in your head and in whichever functions happened to remember it. The moment a second code path mutates an input without re-running your hand calc, you have two truths. One of them is a bug, and it's usually the one in production, discovered by a customer.
Where manual calculation actually earns its keep
I'm decisive, not religious. There are exactly two cases where storing a hand-calculated value is correct, and both are about semantics, not speed. First: the value is a fact, not a derivation. An invoice total at the moment of purchase must never change because you re-ran today's tax rate against a two-year-old order. Freeze it, persist it, treat it as immutable history. Second: the computation is provably expensive and read-heavy under a write-light workload — a denormalized aggregate over millions of rows, recomputed nightly. Notice both cases require you to take ownership of staleness on purpose, with a comment explaining why. Everything else — 'it might be slow,' 'it's just easier here' — is laziness wearing a performance costume. If you can't name the invalidation strategy, you haven't earned the right to store it.
The failure mode nobody admits to
Manual calculations don't fail loudly. They fail three sprints later when someone adds a discount field and updates the line-item logic but not the four other places that recompute the order total. Now the cart says $90, the receipt says $100, and the analytics dashboard says $95, and you get to spend a Friday afternoon figuring out which one is lying. Computed properties make that class of bug structurally impossible — there is one formula, and it reads every input live. The cost you pay is recomputation, which is a profiler's problem you can fix with one memoization decorator when and if it shows up. The cost manual calculation charges is correctness, which you fix by finding every call site, and you will miss one. That's not a hypothetical. That's the most common data-integrity bug I see, full stop.
How to choose without overthinking it
Ask one question: is this value derived from other state I already hold? If yes, compute it. Default to the computed property and don't negotiate with yourself. Reach for memoization only after a profiler — not your intuition — shows recomputation is the bottleneck; premature caching just reintroduces the staleness bug you avoided. Reach for a stored manual value only when the number is a historical fact that must be frozen, or when you can write down a concrete, testable invalidation rule. If you can't articulate when the stored value becomes wrong and how it gets refreshed, you don't have an optimization — you have a future incident with your name in the git blame. Compute by default, store on purpose, and never confuse 'I typed the math myself' with 'I understand the data.'
Quick Comparison
| Factor | Computed Properties | Manual Calculations |
|---|---|---|
| Drift / staleness risk | Recomputed on read — physically cannot go stale | Stored values silently rot when an input changes elsewhere |
| Performance on hot paths | Recomputes every access unless memoized; naive use can be wasteful | Compute once, read cheaply — wins when reads dwarf writes |
| Single source of truth | Formula lives in one place; callers can't disagree | Logic duplicated across call sites, guaranteed to diverge |
| Point-in-time correctness (audit/invoice) | Always reflects current inputs — wrong if you needed the old value frozen | Captures the value as it was; correct for snapshots |
| Cognitive load / debuggability | Read the declaration, know the value; clear dependency graph | Trace every mutation to trust the number |
The Verdict
Use Computed Properties if: Your value is purely a function of other state — totals, full names, filtered lists, formatted strings. Let it compute. Cache it if profiling proves you need to, not before.
Use Manual Calculations if: The computation is genuinely expensive AND the inputs change far more often than the output is read, or the 'derived' value must be frozen at a point in time (an invoice total at purchase, an audit snapshot). Then store it deliberately and document why.
Consider: The real question is never 'compute vs store' — it's 'is this value derived or is it a fact?' A fact gets persisted. Derived data gets computed. People reach for manual calculation because computing felt slow once in 2014.
Derived data should be derived. Computed properties make the relationship between inputs and outputs a single source of truth, so they can't drift. Manual calculations scatter that relationship across every caller and dare you to keep them in sync forever. You will lose that dare.
Related Comparisons
Disagree? nice@nicepick.dev