The `popstate` Event: Handling Browser History Navigation
The popstate event lets your app react to browser back/forward clicks. It's key for SPAs to update views without a full reload. The main footgun: the event fires before the document is fully updated, so your handler might read a stale DOM.
Why it exists
In the era of static HTML, the back button re-fetched a previous page from the server or cache. For modern Single-Page Applications (SPAs), where the "page" is dynamically generated by JavaScript, clicking "back" should update the application's state, not trigger a full server round-trip. The popstate event was created to give developers a hook into this browser action.
The mental model
Think of popstate as an alarm that goes off when someone uses the browser's time machine (the back and forward buttons). Your application can listen for this alarm to know it needs to change its current state to match a previous one, without reloading everything from scratch. It connects the browser's native UI to your application's internal routing logic.
How it works
The browser maintains a session history stack. When you use history.pushState(stateObject, '', '/new-url'), you add a new entry to this stack without making a network request. When the user later navigates back to this entry (via the back button or history.back()), the browser fires a popstate event. The event object contains a state property, which is a copy of the stateObject you originally pushed. Your event listener can then use this state to restore the UI. Importantly, calling pushState or replaceState itself does not fire the event; only a navigation action does.
When to use it
Use popstate as the core of a client-side router in a Single-Page Application. When a user clicks an internal link, you use history.pushState() to change the URL and update the UI. Then, you listen for popstate to handle cases where the user navigates using the browser's back/forward buttons, ensuring the UI stays in sync with the URL.
When not to use it
Do not rely on popstate for tracking every URL change. It only fires on explicit history navigation (back/forward buttons, history.go()). It does not fire when you programmatically change the history with pushState or replaceState. Also, avoid complex DOM manipulation directly inside the event handler without accounting for timing issues.
One canonical example
A classic footgun is reading the DOM too early. popstate fires and window.location updates, but the document itself might not be ready. The handler onpopstate = () => { console.log(document.title); } might log the title of the previous page. The reliable pattern is to defer the work: onpopstate = () => { setTimeout(() => { / now update the DOM / }, 0); }. This queues your logic to run after the browser has finished its current tasks, including updating the document.
Interview question
What critical timing issue must developers consider when handling the popstate event?
- a.The event might fire multiple times for a single navigation.
- b.It can only be listened for using an inline onpopstate attribute, not addEventListener.
- c.It fires only after all network requests for the new state are complete.
- d.The event fires before the browser has fully updated the document's DOM to the new URL.Correct
Why? this is the answer
The card explicitly states that the popstate event fires before the document is fully updated, which can lead to reading stale DOM information. Deferring work with setTimeout(..., 0) is suggested to mitigate this. Option C is incorrect as the timing issue relates to DOM updates, not necessarily network requests.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #web apis
- #javascript
- #history api
- #spa
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on web apis — each one lists the topics its interview covers.
See open roles