SPA back button: what event fires and how do you handle it?

WHAT THIS TESTS: This question probes whether you understand the browser's session history mechanics beyond surface-level routing. Interviewers want to see that you know popstate is the event fired when the active history entry changes, that you can type it correctly in TypeScript, and that you are aware of the timing mismatch between window.location and document readiness. It also checks if you know how to reconstruct UI state from the state object carried by the event.

A GOOD ANSWER COVERS: First, name the popstate event on the window object and note that it is a PopStateEvent. Second, show a typed listener using window.addEventListener with the handler argument typed as PopStateEvent. Third, explain that event.state holds the copy of the object previously passed to history.pushState or history.replaceState, and you use that payload to restore the previous view. Fourth, guard against null because event.state can be null when the history entry has no state object. Fifth, mention the zero-delay setTimeout quirk from MDN: if you need to act after the document is fully ready, wrap your handler logic in setTimeout with a zero delay because window.location may already reflect the new URL while the document is still catching up. This shows you have dealt with real browser timing in production.

COMMON WRONG ANSWERS: A major red flag is claiming that history.pushState or history.replaceState trigger popstate; they do not. Another is suggesting hashchange as the primary handler for a modern pushState-based SPA, which confuses two different routing paradigms. Candidates also stumble by forgetting to type the event as PopStateEvent, or by ignoring the null state case, which leads to runtime errors when the user navigates to an entry that was never pushed with a state object.

LIKELY FOLLOW-UPS: The interviewer may ask how you would restore scroll position across history entries, or how you would handle deep links that land on a route without a corresponding history state object. They might also ask how to prevent memory leaks when adding the listener in a framework lifecycle, or how server-side rendering interacts with client-side history restoration.

ONE CONCRETE EXAMPLE: Suppose a photo gallery SPA calls history.pushState with a state object containing photoId 42 and the URL /photos/42 when opening an image. When the user clicks back, the browser fires popstate and event.state equals that object. Your listener reads that ID, fetches metadata if needed, and re-renders the gallery overlay. If you instead need to measure DOM nodes immediately, you defer work with setTimeout so the browser finishes its internal document updates first. Without that deferral, you might read stale layout metrics.

Source: developer.mozilla.org