Accessible progressive UI
Persist only user-owned state
Store preferences and drafts deliberately without turning browser storage into an accidental database.
9 minute lesson
Start from the behavior you can observe. The filter preference can live locally; authoritative issue records still come from the server.
Persistence needs ownership, lifetime, validation, versioning, and a recovery path just like other state. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
It is tempting to serialize the whole component and trust it forever on every future page version. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to choose individual durable values, validate reads, version the format, and provide reset behavior. Make the boundary explicit in code and in the project notes.
Tie the decision back to the larger job: Finish the issue board as a progressively enhanced interface that remains understandable with keyboard, assistive technology, slow networks, and JavaScript failure. Record enough evidence that another developer can repeat the result without relying on your memory.
Corrupt the saved filter, upgrade its shape, clear storage, and verify the board still starts safely. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.
Lesson completed