Computed fields
A computed field holds a {{ }} template instead of a stored value. Its value is
rendered read-only every time the record is read, so it reaches every path the
same way: list rows, detail pages, search, export, and the public surface. Nothing
is saved, because the value is derived fresh from the record each time.
Add one like any other field, choosing the computed type (see
Fields and field types) and giving
it a template.
Two tiers, one template
A template can reference two kinds of data.
Tier 1 is the record's own fields, both native and custom:
{{year}} {{manufacturer}} {{model}} → "2022 Toyota Corolla"
{{qty}} {{unit}} → "340 g"
Tier 2 is related data a module exposes under a namespace. A module can register a context provider, so a computed field can pull in a value the record does not store itself:
{{maintenance.last_performed}} ({{maintenance.last_performed_at | relative}})
→ "Oil change (2 weeks ago)"
A tier-2 provider is only invoked when a template on that kind actually references
its namespace, so a field that never mentions maintenance costs nothing, and the
computed layer never depends on any specific module.
Filters
A {{ }} reference can carry a filter:
{{ value | relative }}formats a date or timestamp as a coarse phrase ("2 weeks ago", "yesterday").{{ value | slug }}makes a URL-safe slug, for building a link.{{ value | default: "fallback" }}substitutes when the value is empty or missing.
Wires use the same templates in their messages and arguments, with one difference:
| relative is computed-fields only, so a wire renders the raw value instead. See
wires.
What it is good for
A computed field is the place for a value that is always a function of other values: a full display name assembled from parts, a quantity with its unit, a "days since last serviced" line, a link built from an id. Because it renders on every read, it never goes stale, and because it is read-only, there is no second copy to keep in sync.