Worked solutions 07 · External synchronization

A. Observe persistence

The namespaced storage value contains an array of fictional event-ID strings. Reloading the same origin can restore it; clearing or unsaving all events persists an empty preference according to the supplied helper. A new port changes the origin and therefore the storage area. This is a browser-local preference, not an account or cross-device save.

B. Choose the right home

Saved count and filtered events are render calculations. Submitted-form validation belongs in the submit handler because a specific user action causes it. Synchronizing savedIds with localStorage is an effect with savedIds and any reactive key dependencies. A resize subscription is an effect whose cleanup removes the same listener. A module-level constant key is not a changing component dependency. Storage failure should leave in-memory interaction working and clearly say persistence is unavailable.

C. Transfer

Parse the JSON text first, assigning its result to unknown. Then require an array, require every member to be a valid slug-like string under the course’s ID rule, and return a deduplicated array such as […new Set(ids)] after validation. Invalid JSON and an array containing a number fail at different stages. The supplied policy can keep a syntactically valid ID absent from the current dataset, but only current records are rendered. Document that choice.

Mock getItem or setItem to throw in a deterministic test and assert that toggling still updates aria-pressed while a storage warning appears. Restore the mock after the test. Do not erase other origin data with localStorage.clear, and do not write within a state updater: React may call pure updater logic again during development checks.