What state belongs in the URL?

Anything a user would reasonably share, bookmark, or reach with the back button: filters, sort, pagination cursor, active tab, search query, and selected entity id. Keep transient UI state (hover, dropdown open, unsaved form text) out of the URL.

router.push or router.replace for filter changes?

Use replace for high-frequency updates like typing in a search box, so the back button does not step through every keystroke. Use push for meaningful navigations the user should be able to undo, such as changing page or opening a detail view.

How does URL state interact with server state caching?

Treat the parsed search params as part of the query key. When the URL changes, the key changes and the data layer refetches or serves a cached entry. This gives you back/forward navigation that hits cache instead of the network.

Why not just put everything in a global store?

A store is process memory: it dies on refresh, cannot be shared, and is invisible to the server. URL state survives reload, is server-readable for SSR, and makes every view addressable. Use the store for state that genuinely should not be in a link.

URL State & Navigation

The fourth state layer: shareable, bookmarkable, back-button-correct UI.

Module 8 · URL State & Navigation

The fourth state layer: search params, routing state, shareable and restorable UI, filter/sort/pagination in the URL, and navigation patterns in the App Router.

The fourth state layer: what belongs in the URL versus a store, encoding filters, sort, and pagination in search params, deep linking, scroll restoration, and App Router navigation without history spam.

About this module

Most candidates name local, global, and server state and stop there. Senior answers add URL state: the layer that makes a view shareable, bookmarkable, back-button correct, and server-renderable.

This module covers what belongs in the URL versus a store, encoding filters and pagination in search params, deep linking, scroll restoration, optimistic navigation, and how URL state interacts with React Query cache keys.

You will learn the practical mechanics too: useSearchParams and router.replace vs push, avoiding history spam while typing, debouncing URL writes, and keeping SSR and client state in sync without hydration mismatches.

Interviewers use this to separate people who have shipped real dashboards from people who have only built demos: filters that vanish on refresh are the classic tell.

Phase 3 (Week 3) of the interview roadmap. Senior Track spans modules 1–19; the Staff Track starts at module 20.

Why this matters

Interviewers use URL state to separate people who have shipped real product surfaces from people who have built demos. Filters that disappear on refresh, a broken back button, or a dashboard link that cannot be shared with a teammate are all symptoms of state parked in the wrong layer.

Key topics covered

Four State Layers
What Belongs in the URL
Search Param Encoding
Filters, Sort & Pagination
Deep Linking
push vs replace
Debouncing URL Writes
SSR & Hydration
Scroll Restoration
Query Keys from URL

Where you'll use it

Keeping product filters and sort shareable and bookmarkable
Driving cursor pagination from search params so SSR can prefetch
Deep linking into a modal or tab without losing browser history
Debouncing a search box so typing does not spam browser history
Syncing URL state into React Query cache keys

The Four State Layers

Most candidates name three. The fourth is where senior answers start.

Frontend state is usually described as local, global, and server state. That model is incomplete. The URL is a state store too: it survives reload, it is readable on the server before React runs, and it is the only layer a user can copy and send to a colleague.

Comparison of the four frontend state layers
Layer	Lives in	Survives reload	Shareable
Local	Component memory	No	No
Global	Store (Zustand/Redux)	Only if persisted	No
Server	Query cache + backend	Refetched	No
URL	Address bar + history	Yes	Yes

Interview framing

Say it explicitly: “I put anything a user would share or bookmark in the URL, server data in a query cache, cross-cutting UI preferences in a store, and everything else in local state.” That one sentence covers most of a state-management round.

What Belongs in the URL

The test: would a user be annoyed if this reset on refresh?

Which state belongs in the URL
Put in URL	Keep out of URL
Search query	Unsaved form input
Filters and sort	Dropdown open/closed
Page or cursor	Hover and focus state
Active tab or step	Toast visibility
Selected entity id	Scroll velocity
Date range	Anything containing a secret

Never in the URL

Tokens, session identifiers, and personal data. URLs leak into browser history, server access logs, analytics tools, and the Referer header sent to third-party origins.

Encoding Search Params

Keep params readable, short, and stable enough to be a cache key.

Prefer flat, human-readable keys: ?q=shoes&sort=price_asc&page=2
Repeat keys for arrays (?tag=new&tag=sale) instead of JSON blobs
Omit defaults: a param equal to the default should not appear at all
Keep key order stable so identical state produces an identical URL
Validate and clamp on read: never trust a hand-edited query string

// Parse once, at the boundary, into a typed object.
type FeedParams = { q: string; sort: "new" | "top"; page: number };

function parseFeedParams(sp: URLSearchParams): FeedParams {
  const sort = sp.get("sort");
  const page = Number(sp.get("page") ?? "1");

  return {
    q: sp.get("q")?.slice(0, 100) ?? "",
    sort: sort === "top" ? "top" : "new",
    page: Number.isFinite(page) && page > 0 ? Math.min(page, 500) : 1,
  };
}

Why omit defaults

Two URLs that render the same view should be the same string. Otherwise you fragment your CDN cache, your analytics, and your query cache keys across meaningless variants.

Filters, Sort & Pagination

The classic dashboard requirement, and the classic interview follow-up.

Filters drive the request, so they should drive the URL. Once the URL is the source of truth, the server can render the first page with data already resolved, and the back button becomes free.

Reset page to 1 whenever a filter or sort changes: stale page numbers produce empty results
Cursor pagination stores an opaque after= token, not a page index
Multi-select filters use repeated keys so partial selection is expressible
Provide a visible 'Clear filters' action that resets to the canonical bare URL

function setFilter(key: string, value: string | null) {
  const next = new URLSearchParams(searchParams);

  if (value === null || value === "") next.delete(key);
  else next.set(key, value);

  next.delete("page"); // any filter change invalidates the cursor
  router.replace(`${pathname}?${next}`, { scroll: false });
}

push vs replace

Get this wrong and the back button becomes unusable.

When to use router.push versus router.replace
Action	Method	Why
Typing in search	replace	One history entry per keystroke is unusable
Toggling a filter chip	replace	Filters are a refinement, not a destination
Changing page	push	Users expect back to return to the previous page
Opening a detail view	push	Back should close the detail view
Applying a saved view	push	It is a deliberate navigation

scroll: false

In the App Router, navigation scrolls to top by default. For filter updates that keep the user in place, pass { scroll: false } or the page will jump on every interaction.

Debouncing URL Writes

Keep the input responsive while the URL lags slightly behind.

Controlled input keeps local state so typing never waits on routing
Debounce the URL write by 250–300ms so history and requests stay sane
Use replace while debouncing; push only on submit or explicit navigation
On mount, seed local state from the URL so a shared link prefills the box
Cancel the pending write on unmount to avoid navigating after teardown

const [text, setText] = useState(() => searchParams.get("q") ?? "");

useEffect(() => {
  const id = setTimeout(() => {
    const next = new URLSearchParams(searchParams);
    text ? next.set("q", text) : next.delete("q");
    next.delete("page");
    router.replace(`${pathname}?${next}`, { scroll: false });
  }, 300);

  return () => clearTimeout(id);
}, [text]);

Deep Linking & Modals

A modal that cannot be linked to is a modal you will be asked to fix.

If a modal shows meaningful content, it deserves an address. Route it, so that sharing the link opens it directly, back closes it, and the server can render its contents for SEO and first paint.

Route-driven modals: /photos/123 renders full page, intercepted route renders overlay
Param-driven modals: ?modal=invite works for lightweight, non-indexable dialogs
Escape and backdrop click should perform router.back(), not just hide the node
Guard against a deep link to a resource the user cannot access: redirect, do not flash

Interview signal

Mentioning that back should close the modal shows you have shipped this. It is the single most common bug in home-grown modal routing.

SSR & Hydration

URL state is the only client state the server can read.

Server Components receive searchParams, so the first render can already have data
No loading spinner on first paint: the HTML arrives with results in it
Because both sides parse the same URL, hydration mismatches disappear
Store state cannot do this: the server has no access to localStorage or memory
Keep parsing in one shared function so server and client agree exactly

// Server Component: data is resolved before HTML is sent.
export default async function FeedPage({
  searchParams,
}: {
  searchParams: Promise<Record<string, string | string[]>>;
}) {
  const params = parseFeedParams(new URLSearchParams(await searchParams));
  const posts = await getPosts(params);

  return <Feed initialPosts={posts} params={params} />;
}

URL as Query Key

Wire the URL into the data layer and navigation becomes cached.

When the parsed params are part of the cache key, going back does not refetch, it reads from cache. Forward navigation to a previously visited filter set is instant, and stale responses cannot overwrite the current view because they belong to a different key.

const params = parseFeedParams(useSearchParams());

const { data } = useQuery({
  queryKey: ["feed", params],   // URL change ⇒ key change ⇒ correct data
  queryFn: () => fetchFeed(params),
  placeholderData: keepPreviousData, // avoid layout flash while refetching
});

Race conditions solved for free

A late response for ?q=sho lands under its own key and is simply ignored by the view rendering ?q=shoes. Key-based caching is the most robust of the standard race-condition fixes.

Scroll Restoration

Returning from a detail page should not dump the user at the top.

Browsers restore scroll natively, but only if the list content is present again
For infinite feeds, persist the loaded page count in the URL or session storage
Reserve item height so restoration does not land on a shifting layout
Suppress auto-scroll on filter updates with { scroll: false }
Restore after data paint, not on mount, or you scroll an empty container

Interview Takeaways

What to say when asked about state management.

Name four state layers, not three: local, global, server, URL
Shareable, bookmarkable, back-button-relevant state goes in the URL
replace while typing, push for real navigations, scroll: false for filters
Omit defaults so one view maps to exactly one URL
Feed parsed params into the query key: caching and race safety come free
Never put tokens or personal data in a query string

Frequently Asked Questions

URL state and navigation interview questions.

Layer

Lives in

Survives reload

Shareable

Local

Component memory

Global

Store (Zustand/Redux)

Only if persisted

Server

Query cache + backend

Refetched

URL

Address bar + history

Yes

Put in URL

Keep out of URL

Search query

Unsaved form input

Filters and sort

Dropdown open/closed

Page or cursor

Hover and focus state

Active tab or step

Toast visibility

Selected entity id

Scroll velocity

Date range

Anything containing a secret

// Parse once, at the boundary, into a typed object. type FeedParams = { q: string; sort: "new" | "top"; page: number }; function parseFeedParams(sp: URLSearchParams): FeedParams { const sort = sp.get("sort"); const page = Number(sp.get("page") ?? "1"); return { q: sp.get("q")?.slice(0, 100) ?? "", sort: sort === "top" ? "top" : "new", page: Number.isFinite(page) && page > 0 ? Math.min(page, 500) : 1, }; }

Action

Method

Why

Typing in search

replace

One history entry per keystroke is unusable

Toggling a filter chip

replace

Filters are a refinement, not a destination

Changing page

push

Users expect back to return to the previous page

Opening a detail view

push

Back should close the detail view

Applying a saved view

push

It is a deliberate navigation

const [text, setText] = useState(() => searchParams.get("q") ?? ""); useEffect(() => { const id = setTimeout(() => { const next = new URLSearchParams(searchParams); text ? next.set("q", text) : next.delete("q"); next.delete("page"); router.replace(`${pathname}?${next}`, { scroll: false }); }, 300); return () => clearTimeout(id); }, [text]);

// Server Component: data is resolved before HTML is sent. export default async function FeedPage({ searchParams, }: { searchParams: Promise<Record<string, string | string[]>>; }) { const params = parseFeedParams(new URLSearchParams(await searchParams)); const posts = await getPosts(params); return <Feed initialPosts={posts} params={params} />; }

const params = parseFeedParams(useSearchParams()); const { data } = useQuery({ queryKey: ["feed", params], // URL change ⇒ key change ⇒ correct data queryFn: () => fetchFeed(params), placeholderData: keepPreviousData, // avoid layout flash while refetching });

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

The Four State Layers

Interview framing

What Belongs in the URL

Never in the URL

Encoding Search Params

Why omit defaults

Filters, Sort & Pagination

push vs replace

scroll: false

Debouncing URL Writes

Deep Linking & Modals

Interview signal

SSR & Hydration

URL as Query Key

Race conditions solved for free

Scroll Restoration

Interview Takeaways

Frequently Asked Questions

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

The Four State Layers

Interview framing

What Belongs in the URL

Never in the URL

Encoding Search Params

Why omit defaults

Filters, Sort & Pagination

push vs replace

scroll: false

Debouncing URL Writes

Deep Linking & Modals

Interview signal

SSR & Hydration

URL as Query Key

Race conditions solved for free

Scroll Restoration

Interview Takeaways

Frequently Asked Questions