In Angular, when would you replace an expensive template method with a pure pipe rather than a computed() signal, and what does each cache?

## The problem both solve Angular re-evaluates every binding each time it checks a view. A template **method** has no memoization, so an expensive one reruns on every check. Angular offers two built-in ways to make the value cached: a **pure pipe** and a **`computed()` signal**. They look interchangeable in simple demos, but they cache in different places, invalidate on different signals, and suit different shapes of data. ## How a pure pipe caches A **pipe** is a class decorated with `@Pipe` whose `transform()` is called from a template expression such as `{{ value | money:'EUR' }}`. Pipes are **pure by default**; `pure: false` opts out. - The cache is **per usage per view**: each place the pipe appears, in each view instance, remembers its own last arguments and last result. Inside an `@for`, every row's embedded view has its own entry. - Angular re-runs `transform()` only when **any argument changes by identity** (primitives by value, objects and arrays by reference). - It keeps **only the last result**. Alternating between two inputs recomputes every time; this is not a general memo table. - A **mutation** inside an object or array argument is invisible: same reference, no re-run. - An **impure** pipe (`pure: false`) runs on every check, which is exactly the cost you were trying to remove. ## How computed() caches `computed()` from `@angular/core` creates a read-only signal derived from other signals. - It is **lazy**: nothing runs until something reads it. - It is **memoized**: after the first read it returns the cached value until a signal it read during its last run changes. - Its dependencies are **tracked automatically** from the signals it actually read. A plain class field read inside it is not tracked, so changing that field does not invalidate the value. - It lives **once per owner** (component or service instance), not per template usage, and it takes no arguments. ## Side-by-side | Aspect | Pure pipe | `computed()` | |---|---|---| | Where the cache lives | Each template usage in each view | The component or service instance | | What invalidates it | A changed argument (by identity) | A change in a signal it read | | Takes per-row arguments | Yes, naturally in `@for` | No; derive a whole collection instead | | Works with non-signal data | Yes | Only signal reads are tracked | | Reuse across components | Import the pipe anywhere | Scoped to its owner | | Sees in-place mutation | No | No (unless a signal is set) | ## Choosing between them 1. **Per-value formatting in templates** (currency, units, status labels) is pipe territory: stateless, reusable, and naturally cached per row. Built-in pipes like `currency` and `date` are pure. 2. **Values derived from component state**, such as a filtered list, a grand total or a sort order, belong in `computed()`, especially in a signal-based component where inputs are already signals. 3. **Per-row values that depend on several state signals** are usually cleaner as a `computed()` that maps the rows into **view models** with the derived fields already filled in, then iterated with `@for ... track vm.id`. 4. **Non-signal inputs** (a legacy `@Input()` holding an object, data from an observable) favour a pipe, or converting the source to a signal first. ## Why per-row caching matters in a large list Consider a 500-row order list where each row shows a formatted line total. With a template method, every check of the view formats 500 values. With a pure pipe, each row's embedded view holds its own cache entry, so a check where no row object changed costs 500 identity comparisons and zero formatting. If one row's quantity is replaced, only that row's `transform()` runs. A `computed()` that maps the whole list gives the same saving between data changes, but when any row changes it recomputes every row, because it caches the list as one value. That difference rarely matters for cheap formatting and can matter for expensive per-row work. ## Common mistakes - Marking a pipe `pure: false` to "fix" stale output after mutating an array; replace the array instead. - Writing `computed(() => this.rows.filter(...))` where `rows` is a plain field; it computes once and never updates. - Expecting a pure pipe to remember many argument combinations; it keeps one. - Assuming either approach removes the cost of **rendering** many rows; they remove repeated **calculation**, not DOM work. Both are the idiomatic answer to "don't call methods in templates". The interview signal is knowing that the pipe caches by argument identity at each call site, while `computed()` caches by signal dependency on its owner.