Worked solutions 09 · URL-driven screens

A. Navigate like a user

The known fragment route should show its event heading and a matching document title. A copied full URL and refresh should preserve the selected screen on the same local server. Back and Forward should select history entries. An unknown event ID shows Event not found; an unmatched route shows Page not found. Both offer a return link. Record focus rather than assuming a routing library moved it. The supplied heading helper focuses its heading after the selected screen changes.

B. Repair a missing record

The non-null assertion tells TypeScript to assume a value exists; it adds no runtime test. If find returns undefined, reading title throws. Use an explicit if (!event) branch with a message and return link before rendering its fields. If records have not loaded, handle loading or failure first, because an empty not-yet-loaded value does not establish absence.

C. Transfer

Add a route such as /about with a component explaining that all events and form data are fictional, no registration occurs, and preferences stay in the browser. Link to it with Link, use a unique heading, and apply the same title/focus policy. The reference’s explorer filters are local to each screen and reset when that screen unmounts; saved IDs live above the routes and remain shared. Preserving filters instead is a valid extension if state is moved to a lasting owner or a deliberate URL representation. Do not store form fields in the fragment or query string.