What invalidates a cached derived value in a component framework, and how is its dependency set determined?

A **cached derivation** is a computed value that remembers the inputs it last ran with and the result it produced. Asked for the value again, it compares the current inputs against the remembered ones; if they match it returns the stored result, and if they do not it recomputes and stores the new pair. Everything that is interesting about such a cache follows from one question: **what counts as an input?** That set is the dependency set, and it is the whole correctness story. ## Where the dependency set comes from Frameworks obtain it in one of two ways, and the failure modes differ: - **Declared by hand.** You list the values the computation depends on alongside it. The runtime compares the listed values between evaluations and recomputes when one differs. The list is a claim you make, and nothing checks it against the body of the computation, so it can be wrong — or can rot when someone edits the body later. - **Tracked at read time.** The runtime runs the computation once with recording turned on and notes every reactive value it actually read. Those reads become the dependency set, recorded fresh on each recomputation. The set cannot disagree with the body, because the body produced it. Tracking is not magic. It records reads that go **through the tracked source**. A value pulled out of tracking beforehand — copied into a plain local, captured earlier, read through something the runtime does not observe — is invisible to the recorder, and a change to it will not invalidate anything. Conditional bodies also narrow the set honestly: a branch that did not run this time contributed no reads, so a value only read in the untaken branch is not a dependency until the branch runs. ## What invalidation actually means Invalidation is not the same as recomputation: 1. A write to a dependency **marks the cache dirty** — the stored result is no longer trusted. 2. Depending on the design, the runtime either recomputes **eagerly** as part of processing the write, or **lazily** on the next read of the derived value. 3. A lazy derivation that nothing reads may never recompute at all, which is a feature: unwatched work is skipped. Batching sits on top of this: several writes in one turn typically produce one dirty mark and one recomputation, not one per write. ## The two ways it goes wrong | Symptom | Dependency set | Cause | Fix | |---|---|---|---| | Serves an old result after state changed | too narrow | an input the body reads is missing from the set, or was read outside tracking | add it to the set, or read it through the tracked source | | Recomputes on every request | too broad or unstable | an input is rebuilt fresh each time, so the comparison never matches | derive from the stable underlying values, or compare the parts that matter | The second row is the more common and the less noticed, because nothing is visibly broken: the value is always correct, the cache simply never hits, and the code now pays the computation **plus** a comparison plus the memory of a result it never reuses. A useless cache is a cost with no benefit and it looks exactly like a working one. ## Diagnosing either symptom - For a stale value, list what the body reads and compare that list with the dependency set, line by line. Look especially for values that were captured or copied before the computation ran. - For a cache that never hits, look at what the inputs *are* rather than what they mean: a collection or object created inside the caller, a value assembled from fields each time, a default constructed on the spot. Those change identity on every request even when nothing about the data changed. - Check the timing, too. If recomputation is lazy, the work appears at the moment of a read, which can be a surprising place, and the value can look "late" without being wrong. ## What to say in an interview Two sentences carry most of the credit. First: a cached derivation is a remembered pair of inputs and result, and the dependency set decides when the pair is thrown away. Second: get the set too narrow and you serve a stale value; get it too broad or let an input be rebuilt each time and the cache never hits, which costs more than not caching. Adding that hand-declared sets can drift from the body while tracked sets cannot — and that tracking only sees reads that pass through the tracked source — shows you know the mechanism rather than the incantation.