Skip to content
tezvyn:

Programmatically change SPA URL without reload and what is state for?

Source: developer.mozilla.orgEasyHow cards are made

Programmatically change SPA URL without reload and what is state for?

This tests History API fluency. Answer: use pushState or replaceState to change the URL silently; the state object is serializable data tied to the history entry, surfaced through popstate on back or forward navigation.

What's really being asked

This question checks if you know how modern single-page applications synchronize the browser URL with the current view without causing a full page reload. It also checks whether you understand the difference between merely changing the address bar and managing session history in a way that respects the back and forward buttons. Interviewers want to see that you have used the History API in practice and that you understand the lifecycle of the state object.

The full answer

First, name the two methods: history.pushState() creates a new history entry and updates the URL, while history.replaceState() mutates the current entry in place. Second, clarify that both methods accept three arguments: a state object, an unused title string, and a URL. Third, explain that the state object must be serializable and is attached to that specific history entry; when the user later navigates back or forward to that entry, the browser fires a popstate event whose event.state property contains the previously saved object. Fourth, note that these APIs do not cause a network request or page reload by themselves, so the application must manually fetch and render the new content.

The mistakes people make

A major red flag is suggesting location.href, window.location.assign(), or window.location.replace(), because all of these trigger a full document load. Another mistake is confusing the state object with query parameters or the request payload; the state object is never sent to the server and lives purely in the browser's session history. Some candidates also forget to mention the popstate event, which makes it sound like they have not actually built back-button handling in an SPA.

What usually comes next

An interviewer might ask how you would restore scroll position when a user presses the back button, or how you would guard against duplicate history entries when the same link is clicked twice. They might also ask about the security rule that the URL must be same-origin, or how you would polyfill or gracefully degrade for older browsers. Another common follow-up is asking how this approach compares to hash-based routing.

A concrete example

Suppose a photo gallery SPA displays image one at a time. When the user clicks the next arrow, the app calls history.pushState({ imageId: 2 }, "", "/photos/2") and then fetches the new image via fetch(). If the user later clicks the browser back button, a popstate event fires with event.state equal to { imageId: 1 }, allowing the app to re-render the first image without any network round-trip for the HTML document itself.

Interview question

What is the primary purpose of the state object passed to history.pushState?

  • a.To store data tied to the history entry and retrieve it later through popstateCorrect
  • b.To instruct the browser to fetch and render the new URL automatically
  • c.To encode the new URL path as a serializable object
  • d.To send serializable data to the server alongside the new URL
Why?

The state object stores serializable data tied to a specific history entry and is surfaced through the popstate event when the user navigates back or forward; it is never sent to the server, unlike query parameters or request payloads.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

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.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles