React Router - The Routing Library That Actually Works

React Router started in 2014 back when React itself was still figuring things out. The idea is simple: different URLs show different components. No more manually parsing window.location like some kind of caveman. The original announcement shows how experimental this all was back then.

The Three Things You Need to Understand

Three main pieces: Routers (the outer wrapper), Routes (URL matching), and Links (navigation that doesn't suck). That's it. Everything else is just optimization and edge cases.

BrowserRouter uses clean URLs (/about) but needs server configuration. HashRouter uses ugly URLs (/#/about) but works anywhere. MemoryRouter exists for testing and server stuff. Pick BrowserRouter unless you have a good reason not to, like when you're deploying to GitHub Pages.

The Remix Merger Confusion

They merged with Remix in 2023, which confused the hell out of everyone. Suddenly React Router could do server-side rendering, which was weird because it was always a client-side thing.

The deal is this: v7 gives you server-side rendering if you want it ("framework mode"), but you can totally ignore it and keep doing client-side routing like before. Most React apps are SPAs anyway, so this doesn't affect you unless you specifically need SEO or initial page load performance. The React Router v7 announcement explains the vision behind the merger.

Version Upgrade Reality

The v5 to v6 migration was a pain in the ass because they completely changed the API. No more Switch, now it's Routes. No more <Route component={}>, now it's <Route element={}>. Nested routing got completely redesigned. The migration codemod helped but couldn't handle all edge cases.

The good news: v6 to v7 is supposed to be non-breaking. I've upgraded three apps so far and haven't hit any show-stoppers, which is honestly surprising.

TypeScript Support That Actually Works

v7 has auto-generated types, which is nice when it works. Route params get typed automatically, loader data gets typed, all that good stuff. But TypeScript with React Router has always been a bit of a dance - sometimes the types are wrong and you end up with as any in weird places. The type generation setup requires some boilerplate but pays off in larger apps.

The error messages are still cryptic as hell, but at least now you get compile-time errors for broken routes.

Production Reality Check

I've used React Router in everything from side projects to apps with millions of users. It works, it's stable, and when something breaks it's usually your code, not React Router. The bundle size analysis shows ~45KB, it plays nice with code splitting, and it doesn't do anything too magical that you can't debug. Companies like Airbnb and Netflix have used it at massive scale.

The main gotcha is nested routing, which looks simple in the docs but will make you question your life choices when you're trying to implement auth guards or complex layouts. Once you get it though, it's powerful.

Performance in the real world: Router transitions are fast - we're talking single-digit milliseconds for route matching. The bottleneck is always your components re-rendering or data fetching, not the router itself. I've seen apps with 100+ routes that still route instantly.

Memory usage stays reasonable even with deep nesting. React Router doesn't keep all components in memory - it properly unmounts routes when you navigate away. The biggest memory leak I've seen was developers keeping state in parent components that never unmounted.

The Framework Mode Thing (New in v7)

They added "framework mode" which basically means React Router can do server-side rendering now. This was confusing because React Router was always a client-side thing, but they merged with Remix so here we are. The architectural decision was controversial in the community.

Framework mode works fine if you need SEO or initial page load performance. But here's the thing - SSR is a pain in the ass and most React apps don't actually need it. Your dashboard app doesn't need to be indexed by Google.

If you do enable it, prepare for:

• Hydration mismatches that make no sense
• Environment variables that work in client but not server
• Debugging why your component renders twice (React 18 strict mode makes this worse)
• FOUC (Flash of Unstyled Content) even when you think you fixed it)

Data Loading (Loaders and Actions)

The new loader/action pattern is stolen from Remix and it's actually pretty good. Instead of `useEffect` hell, you load data before the component renders. This follows the React 18 patterns for data fetching:

// This looks clean until you need error handling
export async function loader({ params }) {
  try {
    const response = await fetch(`/api/users/${params.id}`);
    if (!response.ok) {
      // Now what? Throw? Return null? Nobody explains this part
      throw new Error('User not found');
    }
    return response.json();
  } catch (error) {
    // Error boundaries are great until you need custom error handling
    throw error; // Hope someone catches this upstream
  }
}

The problem is error handling gets weird. Loaders can throw, which triggers error boundaries, but sometimes you want to handle errors differently per route. The docs make it look simple but real apps have complex error scenarios. Kent C. Dodds explains why this gets complicated.

Also, TypeScript support is great when it works. Route params get auto-typed, loader data gets typed, but sometimes the generated types are wrong and you're back to as any.

Nested Routing (Where Dreams Go to Die)

Nested routing looks elegant in examples but becomes a nightmare in real apps. You'll spend hours figuring out why your layout component isn't rendering child routes, or why auth guards aren't working for nested routes. The official nested routing guide helps but doesn't cover edge cases.

// This looks simple
<Route path=\"dashboard\" element={<DashboardLayout />}>
  <Route path=\"users\" element={<Users />} />
  <Route path=\"users/:id\" element={<UserDetail />} />
</Route>

// Until you need auth guards and realize the auth check 
// runs for every nested route separately

The <Outlet /> component is where your routes render, but figuring out where to put it in complex layouts is like solving a puzzle. And don't get me started on passing data between parent and child routes - it's possible but not obvious.

Code Splitting Reality Check

Auto code splitting is nice in theory. Routes get lazy-loaded automatically, which reduces your initial bundle. But:

• It doesn't split where you actually want it to
• Loading states become your problem again
• Users get spinners for every navigation
• Debugging becomes harder when everything's async

The hover prefetching is clever but can waste bandwidth on mobile. And if your API is slow, prefetching route code doesn't help much.

Real bundle impact: In a recent app audit, React Router added 47KB gzipped to our initial bundle. But lazy route splitting reduced our total bundle from 280KB to 185KB. Net win, but not as dramatic as the marketing suggests. Use webpack-bundle-analyzer to see the real impact.

The mobile prefetch problem: Hover prefetching works great on desktop but breaks on mobile since there's no hover. Users on slow connections get hit twice - slow initial load AND slow route transitions. You can disable it per-route, but most people don't.

Migration Experience (v6 to v7)

They promise non-breaking upgrades and mostly deliver. I've upgraded three production apps and only hit minor issues:

• Some TypeScript types changed subtly
• Error handling behavior shifted slightly
• A few edge cases in nested routing broke

Budget extra time even for "non-breaking" upgrades. There's always something. In our last upgrade, spent 4 hours tracking down why our lazy-loaded routes were throwing ChunkLoadError - turned out webpack was caching the old chunk names.

Auth Guards (Still Annoying)

Auth is still handled through loaders instead of route guards. It works but feels backwards:

// Check auth in every protected loader
export async function loader() {
  const user = await getUser();
  if (!user) {
    throw redirect('/login');
  }
  return { user };
}

This means auth logic is scattered across route files instead of centralized. Higher-order components or route wrappers were cleaner, honestly.

The Real Performance Story

React Router itself is fast. The performance problems are usually your code:

• Too many nested routes creating deep component trees
• Expensive components re-rendering on every navigation
• Data fetching patterns that don't play well with routing
• Bundle splitting that creates too many small chunks

The concurrent rendering support is nice but won't magically fix performance issues. Profile your app.

War story: We had a dashboard with 8-level nested routing that was rendering 30+ components on every route change. The issue wasn't React Router - it was our layout components not memoizing properly. Fixed with React.memo() and went from 400ms route transitions to 50ms.

Another gotcha: Large apps with 200+ routes can hit Chrome's navigation timing limits. We started seeing 2-3 second delays during route parsing. The fix was switching from nested JSX routes to the programmatic `createBrowserRouter` approach, which is 10x faster for large route trees. The React Router performance docs explain the tradeoffs.