Q032: URL State, History API and Routing

What Interviewers Want To Evaluate

This question tests whether you understand the URL as part of application state. Interviewers want pathnames, query params, hash, deep links, browser history, pushState, replaceState, back-button behavior, and route restoration.

For senior roles, the strongest answer explains which state belongs in the URL and why.

Short Interview Answer

URL state makes application views shareable, reloadable, bookmarkable, and recoverable. Route identity usually belongs in the pathname, optional view state often belongs in query params, and local transient UI state can stay in memory. The History API lets apps update the URL without a full page reload, but the app must preserve correct back and forward behavior.

Detailed Interview Answer

A frontend app should not hide important state only in memory. If a user filters a table, opens a report tab, or paginates search results, the URL may need to represent that state so the view can be shared or restored.

Not all state belongs in the URL. Draft text, open menus, hover state, and sensitive values generally should not be placed there.

History API

history.pushState creates a new history entry. history.replaceState updates the current entry. Routers build on top of these APIs to manage navigation without full reloads.

Use push when the user expects Back to return to the previous view. Use replace for redirects, default normalization, or state changes that should not create history noise.

Code Example

const params = new URLSearchParams(window.location.search);
params.set("page", "2");
params.set("sort", "recent");

history.pushState(null, "", `?${params.toString()}`);

Framework routers should usually be preferred over calling the History API directly.

Common Mistakes

A common mistake is storing filters only in React state, so refresh loses the view.

Another mistake is pushing history entries on every keystroke, making the Back button unusable.

Architecture Discussion

Define conventions for route params, query params, defaults, canonicalization, and sensitive data. URL state should be parsed and validated because users can edit it.

Internal Working

At runtime, url state, history api and routing is rarely isolated to one component. It affects browser behavior, framework boundaries, user expectations, and operational signals. A senior answer should explain what happens before the user sees the final result, what state is stored, what can become stale, and which layer owns the decision.

A practical way to reason about it is:

user intent
browser or framework mechanism
application convention
failure mode
measurement signal
team standard

Team Architecture Discussion

In a real codebase, this topic should be represented as a convention rather than a one-off implementation. For browser UX primitives, navigation behavior, styling systems, and resilient layouts, teams need a shared default, a documented escape hatch, and review guidance so every feature does not solve the same problem differently.

The architecture should answer who owns the behavior, where configuration lives, how it is tested, and how regressions are detected after release.

Trade-Offs

The trade-off is usually between simplicity, correctness, performance, and flexibility. A simple implementation is easier to ship, but it may not cover edge cases. A more complete abstraction can improve consistency, but it can also hide important behavior or become too rigid.

A senior engineer should name the cheaper option, name the safer option, and recommend the one that fits the product risk.

Real Production Story

A common production failure for this topic is not a syntax error; it is a mismatch between user expectation and system behavior. The feature works in the happy path, but fails when data is large, language changes, permissions differ, JavaScript loads slowly, the network drops, or the user relies on keyboard or assistive technology.

The useful fix is both technical and operational: repair the implementation, add a regression test or checklist, and add a signal that would have made the issue visible earlier.

Enterprise Example

In an enterprise frontend, this concern usually spans multiple teams. One team may own platform defaults, another owns design-system components, and product teams consume the pattern. Without shared ownership, the result becomes inconsistent behavior across routes.

A mature implementation includes documentation, examples, lint or test support where possible, and migration guidance for older code.

Performance Discussion

Performance impact should be measured in the user flow where this topic appears. Watch for extra JavaScript, broad re-renders, layout shifts, unnecessary network requests, long tasks, hydration cost, or slow recovery from errors.

Do not optimize from instinct alone. Use browser traces, React Profiler, field telemetry, or targeted tests depending on the topic.

Security and Reliability Considerations

Reliability means the UI behaves predictably under failure. Security means the browser cannot be tricked into exposing or mutating data outside the intended trust boundary. Even when the topic is not primarily security-focused, consider malformed input, stale state, permission changes, and third-party behavior.

The safest frontend systems assume external data, URLs, storage, feature flags, and browser capabilities can be missing, stale, denied, or malformed.

Lead Engineer Perspective

A lead engineer should turn this into a repeatable team practice. That may mean a design-system component, a shared helper, a route convention, a test fixture, a dashboard, or a code-review checklist.

The lead-level answer is not only "I know how to implement it." It is "I know how to make the right implementation the default for the team."

Key Takeaways

URL State, History API and Routing should be explained through mechanism, trade-off, production risk, and validation. The interview goal is to show that you can apply the concept inside a real frontend system, not only define it.

Revision Notes

URL state is product state when users need share, reload, bookmark, or restore behavior. History updates must respect user navigation expectations.

Follow-Up Questions

1. What state belongs in the URL?
2. What should not go in the URL?
3. How do query params differ from path params?
4. When should you use replace instead of push?
5. Why can back-button behavior break?
6. How do you validate URL params?
7. How does routing affect analytics?
8. What is hash routing?
9. How do you restore scroll?
10. How would you design URL state for a dashboard?

How I Would Answer This In A Real Interview

I would explain that URLs are part of UX. They preserve navigation and make state shareable. Then I would discuss what belongs in path, query, hash, memory, and server state, with careful back-button behavior.