A filter panel keeps its own copy of the filters and also writes them into the address; what goes wrong?

## Two copies of one value When a screen's filters are held in component state *and* written into the address, the application has two representations of one fact and no rule about which is right. Every mutation path must now update both, and paths that are not written by hand update nothing. The result is a class of defects that reproduce reliably for users and rarely for developers, because developers change filters by clicking the panel - the one path that does update both. ## The three symptoms 1. **Back and Forward move the address, not the screen.** The user narrows a filter, presses Back, watches the address revert, and the panel and the results stay as they were. History navigation changes the address without going through the panel's own change handler, so a copy written only by that handler never learns. 2. **A later address change is ignored.** The panel initialised its copy when it first appeared. Any subsequent change of address that does not remount it - an in-app link that sets different parameters, a programmatic navigation, a restored entry - leaves the copy at its initial value while the address says something else. 3. **A sync loop, or a fight over recency.** The usual patch is an effect that copies the address into the state and another that copies the state into the address. A write on either side now triggers the other, and unless both directions are exactly idempotent the pair oscillates, floods history with entries, or settles on whichever value happened to be applied last - non-deterministically, because it depends on scheduling. ## Why "just sync them" cannot be made safe A two-way sync maintains an invariant with two writers and no arbiter. To be correct it must guarantee that writing an identical value is a complete no-op on both sides, that no ordering of the two effects produces a different outcome, and that an interrupted or superseded navigation cannot resurrect an older value. That is a lot of care for a problem you can delete instead, by removing one of the two copies. ## The fix: one direction only - **Declare the address authoritative** for the state it carries: view, entity, filters, sort, page. - **Derive downward.** The screen reads the current address, parses it once into a typed view model, and renders from that. The panel's checkboxes and menus display derived values and hold no copy. - **Write by navigating.** A user interaction produces a new address, and the screen re-renders because the address changed. Exactly one writer, exactly one reader. - **Make the identity case a no-op.** Choosing the value that is already active should produce no change at all, which removes the oscillation risk by construction. - **Parse in one place.** One function from address to view model, used by the screen, the data layer and the tests, so no two consumers disagree about what a parameter means. Frameworks differ in how the re-render happens - a runtime that re-runs the component function re-reads the address on each pass, one with fine-grained tracking recomputes only the derived values that actually changed, and a compile-time runtime wires those dependencies during the build - but the shape of the fix is the same in all of them: a single source, read through, no mirrored copy. ## Where local state is still correct One-directional derivation does not mean every interaction writes the address immediately. | Situation | State | Commit into the address | |---|---|---| | Text being typed into a search box | local editing buffer | on debounce, or on submit | | A multi-step filter behind an Apply button | local draft | when the user applies it | | Toggling a single checkbox filter | none - derived | immediately, as the interaction | | Optimistic feedback while a navigation resolves | local pending value | dropped when the new address renders | The distinction is committed versus in-progress. In-progress input is legitimately local, because it is not yet a place the user is at. Once committed it belongs to the address, and the local buffer stops being authoritative. ## Testing it Drive the address, not the panel. Set an address and assert the panel shows the matching values; change the address to a different set and assert the panel updates without remounting; step back through history and assert the panel follows; choose the value that is already active and assert nothing changes. A screen that passes those cannot be holding a hidden second copy.