URL as state

Some state describes what the user is looking at — that state belongs in the URL, not useState. A filter selection, the active tab, the current page, the search query: these all answer “what view is this?”. The URL exists precisely to encode the current view as an addressable, copy-pasteable string. Putting that state in useState makes it invisible to the address bar — so it can’t be shared, bookmarked, or restored.

// useState: the view is private to this render. Refresh and it's gone;
// copy the URL and the recipient sees a different view.
const [category, setCategory] = useState("all");
const [sort, setSort] = useState("popular");

The test: if I copied this URL into another tab, should the page look the same? If yes, that state belongs in the URL.

Read the state from search params, and treat the URL as the source of truth — not a copy of useState. With the App Router, useSearchParams returns a read-only URLSearchParams; you derive your view directly from it. There is no second useState mirroring the value, so there is nothing to keep in sync.

"use client";
import { useSearchParams } from "next/navigation";

function ProductList() {
  const params = useSearchParams();
  const category = params.get("category") ?? "all";   // URL is the source
  const sort = params.get("sort") ?? "popular";
  return <Grid items={query(category, sort)} />;       // UI = f(URL state)
}

Notice the shape: UI = f(state) still holds, but state now lives in the URL. The component is a pure function of the search params — refreshable and linkable because its entire input is in the address bar.

Write the state by updating the URL — a navigation — so Back/Forward and refresh come for free. To change the filter you push a new URL; the router re-renders the page with new search params, and the browser records a history entry. You never call setState for this value. Build the next query string from the current params so you change one key without clobbering the rest.

"use client";
import { useSearchParams, useRouter, usePathname } from "next/navigation";

function CategoryFilter() {
  const params = useSearchParams();
  const router = useRouter();
  const pathname = usePathname();

  function setCategory(next: string) {
    const q = new URLSearchParams(params);   // start from current URL
    q.set("category", next);                  // change one key
    router.push(`${pathname}?${q}`);          // a navigation, not setState
  }
  return <Select value={params.get("category") ?? "all"} onChange={setCategory} />;
}

Because each change is a real navigation, the Back button steps to the previous filter and a reload restores the exact view — behaviour you’d otherwise have to rebuild by hand with useState + localStorage + effects.

The failure mode: pushing transient, high-frequency state into the URL spams history and re-renders on every change. The URL is the right home for committed, low-frequency view state. It is the wrong home for the per-keystroke value of an input, a hover, a half-open dropdown, or a drag position. Each router.push is a navigation: it adds a history entry (so one search “shoes” becomes five Back presses — s, sh, sho, sho e, shoes) and re-renders the route subtree on every change.

// WRONG: every keystroke is a navigation — history is now junk, and the
// whole route re-renders on each character.
function Search() {
  const router = useRouter(), pathname = usePathname();
  return <input onChange={(e) => router.push(`${pathname}?q=${e.target.value}`)} />;
}

The fix is split storage by frequency: keep the live input value in local useState (transient, fast, private), and commit to the URL only on a debounce or on submit — and use router.replace (no history entry) instead of push for incremental commits. The URL holds the committed query; useState holds the keystrokes.