Type-Safe Routing

Routing is where TypeScript codebases often stop telling the truth. You define a path as a string in one file, parse useParams() in another, and hope the two stay aligned. Search parameters drift into URLSearchParams soup. Navigation targets are copy-pasted URLs that nobody refactors when the route shape changes. For experienced React developers, the frustration is not “routing is hard”—it is that the type system usually gives up exactly at the boundary where mistakes are cheapest to make and most expensive to fix.

By 2026, the ecosystem has split into two serious answers. TanStack Router has carved out a niche as the router that treats TypeScript as a first-class design constraint: path params, search params, loader data, and router context are inferred end-to-end, with validation hooks (often Zod) sitting on the search layer instead of scattered as casts. React Router v7, released in November 2024 after the merge of Remix’s full-stack model into the React Router lineage, dominates by distribution—on the order of twelve million weekly downloads—and by integration depth: file-based route modules, loaders and actions, progressive enhancement patterns, and React Server Components where your deployment supports them. TanStack Router’s growth story is visible in npm trends (on the order of 1.2M weekly downloads and very strong year-over-year growth) and in ecosystem signals such as a July 2025 migration guide aimed at teams coming from React Router v7—evidence that the two are now compared in the same breath, not as “experimental vs default.”

This chapter is not a tutorial that pretends one library is “correct.” It is a decision framework for TypeScript-heavy teams.

Choose TanStack Router when you are building a client-rendered SPA (or a hybrid where the client router owns most navigation), when compile-time guarantees on navigation matter more than server-first data APIs, and when you want Zod-validated search params and typed Link/navigate targets without maintaining parallel type definitions. The runtime footprint is modest—on the order of 40KB—and the router is framework-agnostic enough to travel with TanStack’s broader stack (Query, Table, etc.) without assuming a specific meta-framework.

Choose React Router v7 when you are shipping a full-stack application: nested layouts that mirror filesystem routes, loaders that run in the right environment for your adapter, actions for mutations, and RSC when your hosting and bundler pipeline are ready. If your team already lives inside the React Router mental model, v7 is less a pivot than an upgrade path that absorbs Remix’s strengths. Next.js App Router remains its own axis; this chapter focuses on the TanStack vs React Router comparison because both target “typed routes” while optimizing for different topologies (SPA inference vs server-integrated routing).

Use a hybrid mental model when you are on Next.js or another meta-framework: the router bundled with the framework may already encode file conventions and server boundaries. In that world, the skills from this chapter still apply—typed search params, colocated loaders, protection at data boundaries—but the “which package?” question is partly answered for you.

The two sections that follow go deep on each contender. TanStack Router: 100% Type-Inferred Routing walks through file-based routes, loader data inference, Zod-backed search validation, typed links, and router context—showing what “zero manual assertions on params” actually looks like in practice. React Router v7: Full-Stack Routing with RSC explains generated route module types, typed loaders and actions, protection via loaders, and where inference still requires explicit imports compared with TanStack’s more seamless client-side inference.

By the end of this chapter, you should be able to justify a router choice to your team in one paragraph: not from marketing copy, but from where types are inferred, where the server runs, and what happens when a route changes in a large TypeScript codebase.