Question presented to candidate: "React has no built-in router. How do you choose one, and what does that choice actually commit you to?"
What a strong answer should cover:
- React has no router. It renders a tree; mapping URLs to trees is a separate concern, which is why several credible options exist.
- The real fork is client-side routing versus server-side routing, because it decides where data loading lives — not which API you prefer.
- Client routing (React Router, TanStack Router): the URL is client state, the router swaps components, navigation is instant after load. Data loading is yours to arrange.
- Server routing (Next.js App Router and similar): the URL maps to files, the server can render and stream the new segment, and data loading is part of the route.
- The critical shared idea is route-level data loading — starting the fetch on navigation rather than after the component mounts, which is what avoids the classic waterfall.
- Every router must handle the same list: nested layouts, URL params and search params, code splitting per route, pending and error states, and scroll restoration.
- Search params are state — filters, sort order, pagination — and putting them in the URL makes them shareable, bookmarkable and back-button-correct for free.
- A tiny app may need nothing: conditional rendering on a state value is a legitimate answer for two screens.
Clarifying questions expected:
- "Is this content public and crawlable, or an authenticated app?" — that leans the client/server decision.
- "Do we already have a framework?" — the router usually comes with it.
Code / implementation expected: Optional. Naming the decision axis matters more than API syntax.