A store selector rebuilds a filtered, sorted list on every notification — how do you memoise it and why might its cache never hit?

A **selector** is a function from the whole of a store's state to the slice a particular reader wants. Cheap selectors just reach in and return a reference. The interesting ones **derive**: filter a collection by the current criteria, sort it, group it, total it, join two slices together. Deriving inside a selector is the right place for it — the rule lives once, next to the data, rather than being repeated in every component that needs the result. The problem is that a selector runs whenever its reader is asked to produce output, which can be on every store notification, including notifications caused by parts of the state the selector never touches. If the derivation is heavy, that is real repeated work on something that did not change. ## The two-stage shape The standard answer is to split the selector in two: - **Input steps** are trivial and pure reference plucking: the collection, the filter criteria, the sort key. They run on every call and cost nothing. - **A combining step** holds the expensive derivation and a small cache of its last inputs and last result. Called again, it compares the inputs it was handed — by identity, which is why the input steps must return references rather than build anything — and returns the stored result if they match. That is the meaning of *memoising on input identity*: the cache does not inspect the collection's contents, it asks whether it was handed the same collection object and the same criteria as last time. Immutable updates make this work, because a collection that was not written is the same object, and one that was written is a different object. ## Why the cache never hits Nearly every "my memoised selector still recomputes every time" report is an input step that manufactures a value: | Input step returns | Why the cache misses | |---|---| | a freshly built collection (a filtered, mapped or concatenated one) | new identity each call, even when the contents are identical | | an object or record assembled from several fields | assembled on the spot, so never the same object twice | | a default substituted when the slice is missing | a new empty collection or object each call | | a value read from somewhere the store does not own and that is replaced each turn | changes for reasons unrelated to the derivation | The rule that follows: **input steps return references, the combining step creates**. Anything that constructs belongs after the cache, never before it. If an input genuinely must be assembled, derive it in its own memoised step first, so the assembly has its own cache and a stable result to hand downstream. ## One cache, many callers A second failure is subtler. A memoised derivation typically keeps **one** remembered pair. Give that single cache several callers with different arguments — one component selecting items for user A and another for user B — and each call evicts the other's entry. Every call then misses, and the code is slower than the uncached version because it also pays the comparisons. The ways out: 1. **A cache per reader.** Create a selector instance per component instance, so each has its own entry. 2. **A cache keyed by the argument**, with a bounded number of entries and an eviction rule, so several arguments coexist. 3. **Move the argument into the derivation**, deriving a map from argument to result once, and letting each reader look up its key. Which one is right depends on how many distinct arguments there are and how big each result is: a cache that holds one entry per user of a large app has become a memory decision, not just a speed one. ## Practical rules - Memoise the expensive step only. A filter over a handful of items does not need a cache; a sort and group over thousands does. - Keep derivations out of the reader wherever the same derivation serves more than one reader — one cache beats several. - Remember that a derivation returning a new collection on a miss hands a new identity downstream, so anything that compares by identity sees a change on every genuine recomputation. That is expected; what is not expected is a new identity on a **hit**, which means the cache is not being consulted at all. - Verify a cache rather than trusting it. A counter incremented inside the expensive step, read after a few interactions, settles the question faster than reasoning about it. ## Interview framing Say the shape out loud: cheap input steps that pluck references, one memoised combining step holding the derivation, identity comparison between them. Then name the classic defect — an input step that builds something, so the comparison never matches — and the second one, a single-entry cache shared by callers with different arguments. Finishing with "and I would confirm the cache actually hits before believing in it" is the part that reads as production experience.