Routing with React Router

In a classic multi-page website, every link click asks the server for a brand-new HTML document. The browser throws away the current page — all your React state, every open dropdown, every scroll position — and rebuilds everything from scratch. You see the white flash, the spinner, the re-downloaded JS.

A React single-page application (SPA) loads one HTML page once. After that, "navigating" should just mean swap which components are on screen. But two problems appear the moment you try to fake pages with plain state:

• The URL never changes — users can't bookmark, share, or refresh into a specific screen
• The Back/Forward buttons break — the browser thinks you never left

The fix is a browser API called history.pushState. It updates the address bar and adds a history entry without triggering a page load:

// This is (conceptually) what a router does on every <Link> click:

// 1. Stop the browser's default full-page navigation
event.preventDefault();

// 2. Update the address bar + history — NO request, NO reload
history.pushState({}, '', '/about');

// 3. Re-render: match the new URL against your route table
//    and swap in the right components
renderRouteFor(window.location.pathname);

// 4. Listen for Back/Forward so those work too
window.addEventListener('popstate', () => {
  renderRouteFor(window.location.pathname);
});

You could build this by hand — many of us did, once, as a rite of passage — but it gets hairy fast: URL params, nested layouts, redirects, scroll restoration, data loading. React Router is the de-facto standard library that handles all of it. Ang importante dito: the router's whole job is keeping the URL and your UI in sync, in both directions.

One package, whether you're on Vite, CRA, or anything else that renders in a browser:

npm install react-router-dom

Modern React Router (v6.4 onwards, including v7) wants you to define routes as a data structure with createBrowserRouter, then hand it to RouterProvider:

import React from 'react';
import ReactDOM from 'react-dom/client';
import { createBrowserRouter, RouterProvider } from 'react-router-dom';
import Home from './pages/Home';
import About from './pages/About';

const router = createBrowserRouter([
  { path: '/', element: <Home /> },
  { path: '/about', element: <About /> },
]);

ReactDOM.createRoot(document.getElementById('root')).render(
  <React.StrictMode>
    <RouterProvider router={router} />
  </React.StrictMode>
);

You'll also still meet the classic JSX style in older codebases and tutorials — BrowserRouter wrapping Routes and Route elements:

import { BrowserRouter, Routes, Route } from 'react-router-dom';

export function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

Which one should you pick? Both work, and route matching behaves the same. But createBrowserRouter is the one the React Router team recommends, because the data APIs — loader, action, errorElement (sections 9 and 11) — only work with it. Everything in this post uses createBrowserRouter; recognize the classic style, write the modern one.

A route is the simplest possible mapping: when the URL is this path, render this element. Try the mini app below — click Home, About, and Contact and watch the address bar change while the page never reloads.

And the page components are just… components. Nothing router-specific about them:

export default function About() {
  return (
    <main>
      <h1>About</h1>
      <p>We build small, fast apps.</p>
    </main>
  );
}

Routes decide what renders where — Link is how users get there. It renders a real <a> tag (so right-click → open in new tab, hover preview, and accessibility all still work), but intercepts the click and does the pushState dance instead of a full reload.

NavLink is Link with one superpower: it knows whether its to matches the current URL, and hands you an isActive flag for styling. Perfect for nav bars — see how the highlighted pill follows you around:

Real apps don't have a route per user — they have one route pattern that matches them all. A : in a path segment makes it dynamic:

const router = createBrowserRouter([
  { path: '/users', element: <UserList /> },
  { path: '/users/:id', element: <UserDetail /> },
  //             ^^^ ":id" matches /users/1, /users/2, /users/abc…
]);

Inside the matched component, useParams() returns every dynamic segment. Click a user card below and watch the URL — the detail "page" reads the id straight out of it:

You can stack multiple params in one path — each one shows up in the same object:

{ path: '/teams/:teamId/members/:memberId', element: <Member /> }

// In Member.jsx:
// const { teamId, memberId } = useParams();
// "/teams/frontend/members/7" → { teamId: "frontend", memberId: "7" }

Here's where React Router goes from "nice" to "how did I live without this". Most apps have persistent chrome — a navbar, a dashboard sidebar — that should stay put while an inner panel changes. Copy-pasting the shell into every page is the beginner move; the router move is a layout route:

• The parent route renders the shell (sidebar, header)
• Child routes render inside it, wherever the shell places <Outlet />
• An index: true child is the default — what shows at the parent's own URL

Click around the sidebar below. The shell never re-mounts — only the Outlet area swaps:

Notice the child paths in the Code tab: analytics, not /analytics. Child paths are relative — they extend the parent's path. That's how /dashboard + analytics becomes /dashboard/analytics.

Links cover navigation the user initiates. But sometimes your code decides to move: after a successful form submit, after logout, after a countdown. That's useNavigate — call it like a function, go somewhere:

The useful variations, in one place:

const navigate = useNavigate();

navigate('/welcome');                  // push a new history entry
navigate('/welcome', { replace: true }); // REPLACE the current entry —
                                       // Back won't return to this page
navigate(-1);                          // same as the browser Back button
navigate('/orders', { state: { justCreated: true } }); // pass hidden state
// read it on the other side with: const { state } = useLocation();

Filters, search text, sort order, page number — where should that state live? Put it in useState and it evaporates on refresh; a teammate can't send you a link to "page 3, sorted by price". Put it in the URL and it becomes shareable, bookmarkable, refresh-proof, and Back-button-friendly for free.

useSearchParams is useState for the query string. Type in the search box below and watch the address bar update live:

Two different failure modes, two different tools. First: the URL matches no route at all. The path: "*" splat route catches everything nothing else claimed — your 404 page:

import { Link } from 'react-router-dom';

function NotFound() {
  return (
    <main>
      <h1>404 — Page not found</h1>
      <p>That page doesn't exist (or moved).</p>
      <Link to="/">← Back to home</Link>
    </main>
  );
}

const router = createBrowserRouter([
  { path: '/', element: <Home /> },
  { path: '/users/:id', element: <UserDetail /> },
  { path: '*', element: <NotFound /> }, // matches ANYTHING unmatched — keep it LAST in spirit
]);

Second: a route matched, but something threw — a render bug, a failed loader (section 11), a Response you threw on purpose. errorElement is the route-level error boundary for that:

import { useRouteError, isRouteErrorResponse } from 'react-router-dom';

function ErrorPage() {
  const error = useRouteError();

  if (isRouteErrorResponse(error)) {
    // e.g. a loader did: throw new Response('Not Found', { status: 404 })
    return <h1>{error.status} — {error.statusText}</h1>;
  }

  return <h1>Something went wrong 😬</h1>;
}

const router = createBrowserRouter([
  {
    path: '/',
    element: <RootLayout />,
    errorElement: <ErrorPage />, // catches errors from this route AND its children
    children: [
      { index: true, element: <Home /> },
      { path: 'users/:id', element: <UserDetail />, loader: userLoader },
    ],
  },
]);

Some pages are members-only. The standard pattern is a tiny guard component that wraps a private route's element: logged in → render children; logged out → <Navigate to="/login" />. Toggle the checkbox below and try to visit /profile in both states:

Two details make this pattern production-grade rather than a toy:

The guard passes state={{ from: location }} to the login page, and after a successful login you navigate(from, { replace: true }). Users land on the page they originally wanted — not dumped on the homepage.

// Wrap ONE layout route — every child is protected automatically
{
  path: '/account',
  element: (
    <RequireAuth>
      <AccountLayout />
    </RequireAuth>
  ),
  children: [
    { index: true, element: <AccountHome /> },
    { path: 'orders', element: <Orders /> },
    { path: 'settings', element: <Settings /> },
  ],
}

The classic SPA data flow is: route renders → useEffect fires → spinner → data arrives → re-render. It works, but every page starts with a loading waterfall, and every component carries its own loading/error state boilerplate.

Since v6.4, React Router flips the order: a loader fetches data before the route renders. Navigation waits for the data, then renders the page complete. The component just reads the result with useLoaderData():

import { useLoaderData } from 'react-router-dom';

// Runs BEFORE the component renders. Route params come in as an argument.
export async function userLoader({ params }) {
  const res = await fetch(`/api/users/${params.id}`);

  if (!res.ok) {
    // Thrown Responses are caught by the nearest errorElement
    throw new Response('User not found', { status: 404 });
  }

  return res.json();
}

export function UserDetail() {
  // No useEffect, no loading state, no null checks —
  // by the time this renders, the data is guaranteed to be here
  const user = useLoaderData();

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.role}</p>
    </div>
  );
}

// Wire it up in main.jsx:
// { path: '/users/:id', element: <UserDetail />, loader: userLoader }

action is the write-side twin: it receives form submissions. Pair it with React Router's <Form> component and you get mutations that automatically revalidate every loader on the page afterwards — your UI can't drift out of sync with the server:

import { Form, redirect } from 'react-router-dom';

// Runs when the <Form> below is submitted
export async function newUserAction({ request }) {
  const formData = await request.formData();

  const res = await fetch('/api/users', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name: formData.get('name') }),
  });

  const user = await res.json();
  return redirect(`/users/${user.id}`); // straight to the new detail page
}

export function NewUser() {
  // method="post" submits to this route's action — no onSubmit handler needed
  return (
    <Form method="post">
      <input name="name" placeholder="Name" required />
      <button type="submit">Create user</button>
    </Form>
  );
}

// { path: '/users/new', element: <NewUser />, action: newUserAction }

Honest take: for small apps, useEffect fetching is fine and one less concept. Reach for loaders/actions when you're tired of spinner waterfalls and hand-rolled revalidation — or reach for TanStack Query, which solves overlapping problems (caching, background refetch) and composes well with React Router. More on that in the data fetching post.

Every one of these comes from a real code review. Learn them here instead of in production. 😅

// ❌ BAD: full page reload — the whole React app remounts
<a href="/about">About</a>

// ✅ GOOD: client-side navigation, state preserved
<Link to="/about">About</Link>

// ✅ Plain <a> is CORRECT for external links only
<a href="https://github.com/thirdygayares" target="_blank" rel="noreferrer">
  GitHub
</a>

// ❌ BAD: children match but have nowhere to render
function DashboardLayout() {
  return (
    <div>
      <Sidebar />
      {/* child content silently vanishes */}
    </div>
  );
}

// ✅ GOOD: Outlet marks where children appear
import { Outlet } from 'react-router-dom';

function DashboardLayout() {
  return (
    <div>
      <Sidebar />
      <main>
        <Outlet />
      </main>
    </div>
  );
}

An index route is the child that renders at the parent's own URL. It gets index: true and no path — giving it both is a config error, and giving it path: "/" inside a nested route doesn't do what you hope:

// ❌ BAD: an "index" with a path, or a nested absolute "/"
children: [
  { index: true, path: 'overview', element: <Overview /> }, // config error
]

// ✅ GOOD: index = "what shows at /dashboard itself"
children: [
  { index: true, element: <Overview /> },        // /dashboard
  { path: 'analytics', element: <Analytics /> }, // /dashboard/analytics
]

// ❌ BAD: absolute child path that doesn't extend the parent —
// React Router throws: "absolute route path must start with parent path"
{
  path: '/dashboard',
  children: [
    { path: '/analytics', element: <Analytics /> }, // 💥
  ],
}

// ✅ GOOD: relative child paths extend the parent
{
  path: '/dashboard',
  children: [
    { path: 'analytics', element: <Analytics /> }, // → /dashboard/analytics
  ],
}

// Same idea in Links inside nested routes:
// <Link to="settings">   → relative: /dashboard/settings
// <Link to="/settings">  → absolute: /settings (top level!)

Your scanner-friendly cheat sheet — the seven names you'll type daily:

Cement all of this by building a small "Mini Store" — it touches every concept from this post:

• / — home page with a NavLink nav bar (active styling)
• /products — product grid with ?q= search and ?sort= via useSearchParams
• /products/:id — detail page reading useParams, with a loader fetching from a fake API (or FastAPI, if you followed the backend series!)
• /account — a layout route with Outlet + sidebar (Profile / Orders), wrapped in a RequireAuth guard with a fake login
• After "checkout", navigate("/thank-you", { replace: true })
• A path: "*" 404 page and a root errorElement

If every piece works — active nav, shareable filter URLs, a guard that redirects and then returns you — you genuinely know React Router. Kayang-kaya mo na 'to. 💪

Keep building! 💪 Routing is the skeleton of every real React app — once URLs, layouts, and guards feel natural, you stop building "pages" and start building applications.