The selection in the URL: eight inputs and a real hashchange
In your own project, history.replaceState works (in a try block). The preview is a sandboxed frame, so it refuses.
Linked views react to one shared selection. A tiny store with get, set and subscribe is enough: views never talk to each other, bursts of changes are batched, and the selection can live in the URL if every incoming value is checked.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 4 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write same(a, b) for two ranges (or null) and use it so store.set skips views when nothing changed.
Write the code that updates the URL when a brush ends and restores the brush when the page loads with a hash.
Explain it without notes
Why use a shared store instead of letting charts call each other?
Why does batching with a scheduler draw once for ten changes, and why is that still correct?
What must you check when you read a selection from the URL?
Console
(nothing was printed)Expected console output
#from=2025-06-01&to=2025-06-30 -> 2025-06-01 to 2025-06-30
#to=2025-06-01&from=2025-06-30 -> 2025-06-01 to 2025-06-30
#from=2025-06-01 -> no selection
#from=2025-02-30&to=2025-03-10 -> no selection
#from=2024-01-01&to=2026-01-01 -> 2025-01-01 to 2025-12-31
#from=abc&to=def -> no selection
#from=2025-06-01&to=2025-06-01 -> no selection
(empty) -> no selection
write: #from=2025-06-01&to=2025-06-30 | none: ""
hashchange fired, state read back: 2025-03-01 to 2025-03-31
replaceState: SecurityError