Base Properties vs Computed Properties

Stored, hand-set values versus derived ones computed on demand. One is your source of truth; the other is a formula. Pick the one that matches where the data actually lives.

What they actually are

A base property holds a value directly. You set it, it sits there, you read it back unchanged. A computed property doesn't store anything — it runs a function over other properties every time you ask. firstName and lastName are base; fullName is computed. The distinction matters because it decides where your truth lives and where your bugs hide. Base properties fail by going stale: someone updates one field and forgets the dependent one. Computed properties can't go stale — they're recalculated from scratch — but they fail by being slow, by depending on data that isn't loaded yet, or by quietly assuming their inputs are always present. People conflate the two and then wonder why their 'total' disagrees with the line items. It disagrees because someone stored the total. Don't store the total.

Where base properties win

Some values are not derivable from anything. A user's email, a chosen username, the price at the moment of purchase, a created-at timestamp — there is no formula that reconstructs these, so they MUST be base. Try to make them computed and you've invented fiction. Base properties also win on read performance (no work happens), on indexing (databases index columns, not formulas — mostly), and on auditability: you can see exactly what was stored and when. They're the only honest place to record a decision a human made. The cost is discipline. Every base property that could be derived is a synchronization landmine — a denormalized 'total_price' that drifts the day someone edits a quantity through a path that skips your update logic. Base properties are truth, but redundant truth is just future inconsistency wearing a nice coat.

Where computed properties win

Anything derivable should be computed, full stop. fullName, age from birthdate, isExpired from expiresAt, an order total from its items — compute these and they can never disagree with their inputs, because they have no independent existence to disagree from. This kills an entire bug class: the stale-derived-field. Computed properties also keep your stored state minimal and your schema honest about what's real versus what's convenience. SQL generated columns, ORM computed attributes, Vue/Swift computed properties, spreadsheet formulas — same idea everywhere. The price is real: they recompute on every access, so a computed property over an expensive query inside a render loop will quietly torch your latency. And they can throw when inputs are null in ways a plain stored value never would. Compute freely; just don't compute the same heavy thing ten thousand times and call it elegant.

The rule that ends the argument

Persist base properties. Derive computed properties. When a value can be computed, computing it is almost always correct — you trade a little CPU for zero drift, and drift is the expensive failure. Only promote a computed value to stored (a cache, a denormalized column, a materialized view) when profiling proves the recompute hurts, and then you own invalidation forever. That's the whole tradeoff: storage risks staleness, computation risks cost. Staleness corrupts your data; cost just slows it down — and slow is easier to fix than wrong. So default to computed for anything derivable, default to base for anything original, and never store a number you could have added up. The systems that rot are the ones full of 'cached' totals nobody dares delete because no one's sure they still match. Don't build that.

Quick Comparison

Factor	Base Properties	Computed Properties
Source of truth	Yes — original, authoritative value	No — derived from base properties
Risk of going stale	High if redundant/denormalized	None — recomputed each read
Read performance	Instant, no work	Recompute cost on every access
Storage footprint	Consumes storage permanently	Stores nothing
Auditability of human decisions	Records exactly what was set	Cannot record original intent

The Verdict

Use Base Properties if: You need a durable source of truth, predictable storage, auditability, or a value that no formula can reconstruct (a user's chosen name, a recorded price, a timestamp).

Use Computed Properties if: The value is fully derivable from base data, must never drift out of sync, and you can afford to recompute on read (totals, full names, age, percentages).

Consider: Most real systems want both: persist base properties, expose computed ones. Cache computed values only when the recompute cost actually hurts — and only with explicit invalidation.

The Bottom Line

Base Properties wins

A computed property is only ever as trustworthy as the base properties it derives from. Base properties are the source of truth; everything else is a convenience layer you can rebuild any time. When you must choose what to persist, store the base and compute the rest.

Related Comparisons