An NgRx 22 invoicing dashboard's per-customer view recomputes after almost every dispatched action; what defeats createSelector's memoization, and how do you fix it?

## How the cache decides A selector built with `createSelector` holds **one** cache entry at two levels: the last root state it was called with, and the last results of its input selectors. Both are compared with strict equality (`===`). A hit needs the same **references** as last time; equal contents in a new array do not count. NgRx relies on immutable state to make this sound: an unchanged slice keeps its reference, and a changed one gets a new reference. So "it recomputes on every action" almost always means something is creating new references where the data did not change, or the single cache entry is being overwritten. ## The four usual causes 1. **A deriving input selector.** Inputs run whenever the root state changes, which is after almost any action. If an input filters, maps or builds an object, it returns a new reference each time, so the projector's argument never matches its cache. 2. **A new result from the projector.** When the projector does rerun, `invoices.filter(...)` or `{ invoices, total }` is a new reference even if its contents are identical. Every selector that uses it as an input then reruns too, and `store.select` emits because `distinctUntilChanged` compares with `===`. 3. **One instance, many parameters.** A parameterised selector in the deprecated props form, shared by two widgets showing different customers, overwrites its single entry on each read. Alternating reads always miss. 4. **A factory called on every read.** `selectCustomerView(id)` returns a new selector with an empty cache each time. Calling it inside a template method or getter means no read ever hits a cache. ## Fixing the view ```ts // Misses: the input selector builds a new array on every call export const selectCustomerViewSlow = createSelector( (state: AppState) => state.invoices.items.filter((i) => i.customerId === state.invoices.selectedCustomerId), (own) => ({ invoices: own, total: own.reduce((s, i) => s + i.amount, 0) }) ); // Hits: inputs return stored references; derivation lives in the projector export const selectCustomerView = createSelector( selectInvoices, selectSelectedCustomerId, (invoices, customerId) => { const own = invoices.filter((i) => i.customerId === customerId); return { invoices: own, total: own.reduce((s, i) => s + i.amount, 0) }; } ); ``` Now an action that changes another slice leaves `items` and `selectedCustomerId` identical, and the projector is skipped. | Cause | Symptom | Fix | |---|---|---| | Deriving input | projector runs after unrelated actions | inputs read references; derive in the projector | | New result reference | downstream selectors and views update with equal data | return primitives where possible; content-aware result memoization | | Shared parameterised instance | two widgets both miss | one factory instance per reader | | Factory per read | nothing is ever cached | create the instance once, in a field or `ngOnInit` | ## Keeping the old reference when contents match The fixed selector still returns a new object whenever any invoice changes, because `items` is then a new array. When that re-render matters, NgRx lets you swap the memoizer. `resultMemoize(projector, isResultEqual)` keeps the previous result when the comparator says the new one is equal, and `createSelectorFactory` builds a `createSelector` variant around it: ```ts const createListSelector = createSelectorFactory((projector) => resultMemoize(projector, sameInvoices) ); ``` For signal reads, `selectSignal`'s `equal` option achieves the same at the consumer, but it does not stop the projector from running. ## Diagnosing it - Log or count inside the projector for one session of clicks; a projector that runs on unrelated actions has a deriving input. - Check each input selector: anything beyond a property read or another memoized selector is suspect. - Search templates for selector factories called in methods, getters or bindings. - Confirm reducers return the same slice for actions they do not handle; a reducer that spreads state unconditionally creates new references for everyone. The opposite failure also exists: an **impure** projector, one that reads `Date.now()` for example, returns a stale cached value because nothing it depends on appears in its arguments. Memoization is correct only for pure functions of their inputs. ## When it is worth fixing A projector that sums fifty invoices costs microseconds, and rerunning it after every action is harmless. The fix matters when the projector is expensive, such as grouping thousands of invoices by customer and month, or when its new reference drives a large re-render. Measure first: the Redux DevTools extension shows which slices each action changed, and a projector that runs after an action touching none of its inputs points straight at a deriving input selector.