State & Reactivity

An effect is code a component framework runs after a state change so something outside the component agrees with the new state - a timer, a listener, the document title. Its cleanup runs before each re-run and once at teardown.

Reference comparison asks only whether the new value is the same object as the old one. Writing into a field changes contents but not identity, so the comparison answers "same" and dependent work is skipped. A fresh copy makes it visible.

The lowest common ancestor of both siblings should own it: that component holds the value, passes the current value down as an input to each sibling, and passes down a function each sibling calls to request a change.

Nothing announces a bare assignment. Either the write goes through code the runtime owns - a setter, a tracked handle, or an assignment a compiler rewrote - or the runtime re-checks values later at a moment it was told about.

A store exposes a read of the current value, a write that changes it, and a subscribe that notifies listeners. A component reads while rendering, subscribes when its instance is set up, re-reads once subscribed, and releases the subscription on teardown.

A cached derivation remembers its last inputs and result; a change to an input in its dependency set invalidates it. That set is either declared by hand or recorded from the body's reads. Too narrow serves stale values; unstable inputs never hit.

A declared list re-runs the effect when the listed values change, and silently serves stale data for any value omitted. Automatic tracking records the reactive values actually read during the run, and misses reads made conditionally or after an asynchronous pause.

Replace only the objects on the path from the root to the changed field, and reuse untouched branches by reference. That structural sharing copies a few objects, not the tree, and leaves unchanged branches identity-equal so dependents still skip work.

Nothing updates the copy. An initial value is read once when the state is created, so the component keeps rendering the old snapshot while the parent holds the new value: two truths for one concept.

A re-run-and-diff runtime re-executes the owning component function and produces a whole fresh description of its output, then compares it. A fine-grained runtime walks the subscriptions recorded for that one value and re-runs only those computations.

An action names the change and carries its data, one applier turns it into the next state, and subscribers are notified afterwards. The gain is a single funnel: every change has a name, an order, and one place that enforces invariants spanning fields.

A store created at module scope is one instance per process. A browser process serves one person, so that is what the author wanted; a server process renders many requests at once, and all of them share that instance. Create one store per request instead.

The effect opens a connection per run but never closes the one the previous run opened, so connections accumulate. Cleanup must run before each re-run, closing exactly the connection that run created - not only at teardown.

Tracking lives on the handle, not on the value. A value copied out is a plain snapshot with no link to the handle, so later writes never reach it and nothing re-runs. Read through the handle at each use.

Each pass allocates a different object, and an identity check compares which object it is, not what it holds. Identical contents in a new wrapper report a change, so dependency lists re-fire and children that could skip work do not.

Three independent booleans describe eight combinations when the operation has about four real states, so contradictory ones are reachable and each write must set several flags. One status field with a closed set of named values makes the illegal combinations unrepresentable.

It must see the reactive declaration, the expressions that read it, and the assignment that writes it, inside one compiled unit. Writes it cannot analyse - through a passed reference, from uncompiled code, or via dynamic access - escape.

The read must go through the value's handle while a tracked computation is running. The runtime knows which computation is currently executing and records an edge to it; a read with no such computation active records nothing.

A subscription decides a notification is a no-op by comparing the new selector result with the previous one, usually by identity. A selector that builds a fresh object every call never returns the same identity, so every write anywhere looks like a change.

A glitch is an evaluation with one input refreshed and the other stale, producing a value no state justifies. Runtimes prevent it by settling dependents in dependency order: ordered propagation, marking dirty and refreshing on read, or batching a turn.

Split it: cheap input steps that pluck references, then one memoised combining step holding the filter and sort, cached on input identity. The cache never hits when an input step builds something fresh, or one entry serves differing arguments.

Bundling four concerns gives them one dependency set - the union - so any single change re-runs all four, restarting the timer and re-attaching the listener, and one cleanup block that must undo every combination. Split by trigger, one effect per concern.

Capture the value at the seam across two passes and compare identity and contents as separate facts. Same identity with different contents means an in-place write; new identity with identical contents means a producer allocating each pass. Repair the producer.

Shallow comparison checks each top-level property by reference, which suffices under immutable updates, because a nested change forces new references up the path. A deep comparison walks the graph on every check, so its cost scales with the data.

Decide from the readers, not the depth. List every component that reads or writes the value, take the lowest one containing them all, and compare it with the current owner; the levels between that only pass it along are the cost.

The panel owns draft state that outlives its subject. Either stop storing it and derive the fields from the selected item, give the panel a new identity per item so the old state is discarded, or reset deliberately on selection change.

Cost follows bindings compared per pass times the number of passes, not how many values changed. Narrowing means walking only subtrees the runtime was told may have changed, which requires unchanged inputs to be recognisable by reference.

The read must be synchronous, return the same identity until a write happens, and return a new one after a write. Otherwise the runtime either sees a change on every check and never settles, or never sees one at all.

Answer with a cost model: each cache adds an input comparison, retained memory, a dependency set that can go stale, and review cost. It pays only where compute exceeds the comparison and inputs are stable — so cache at measured hot spots.