React 12 · Ecosystem

Routing (React Router)

Pages, parameters, nested layouts, state in the URL, loaders and protected routes.

Before we start: a hotel with a reception desk

A single-page application is one single HTML page. If it stayed that way, the whole app would have one address – and the user couldn't send a colleague a link to a specific product, bookmark a page or go back with the Back button. That's why we need every "screen" to have its own address, even though it's still one page.

Imagine the app as a hotel:

The URL is the room number. /products/42 = "second floor, room 42". Whoever knows the number gets straight there.
The router is the reception desk. It looks at the number and sends you to the right room – without you having to leave the hotel and come in again (without reloading the page).
The layout is the corridor. The reception, the lift and the corridor carpet are always the same; only the room you walk into changes. In React, the "room door" is the <Outlet /> component.
Search params are requests for the room: ?view=sea&cot=yes. Still the same room, just prepared differently.

1. Reception and rooms: the first routes

A small shop: a home page, a product list, a product detail and a "not found" page.

import { createBrowserRouter, RouterProvider, Outlet, Link, useParams } from 'react-router'

const router = createBrowserRouter([
  {
    path: '/',
    element: <Layout />,                         // the corridor – always visible
    children: [
      { index: true, element: <Home /> },        // exactly "/"
      { path: 'products', element: <ProductList /> },
      { path: 'products/:productId', element: <ProductDetail /> },
      { path: '*', element: <NotFound /> },      // anything else
    ],
  },
])

createRoot(root).render(<RouterProvider router={router} />)

function Layout() {
  return (
    <>
      <nav>
        <Link to="/">Home</Link>
        <Link to="/products">Products</Link>
      </nav>
      <Outlet />                                  {/* the room door */}
    </>
  )
}

The user clicks a link leading to /products/3. What the reception does:

<Link> doesn't cause a page reload. It just changes the address in the browser and lets the router know.
The router goes through the list of routes. / matches the start of the address → it renders Layout. In its children it finds products/:productId, which matches the rest.
Layout renders with the navigation, and ProductDetail appears in place of <Outlet />. The navigation stayed the same – only the room changed.
In ProductDetail we find out the room number with useParams():

function ProductDetail() {
  const { productId } = useParams()          // "3" – always TEXT, not a number!
  const product = products.find((p) => p.id === Number(productId))
  if (!product) return <p>Product not found</p>
  return <h2>{product.name}</h2>
}

The colon in :productId says: "anything can be here, remember it under this name". But the number on a room door is always written – it's text. Hence Number(productId).

Demo

A shop: layout, NavLink, :productId, 404

What you see: The shop from the example above. At the top, a fake address bar with Back/Forward arrows, under it the navigation (the layout) and in the card the content of the current page (<Outlet />).

Try it:

Click Products. The address changes to /products, the button is highlighted (that's what NavLink can do) and the card shows the list. The navigation at the top stayed.
Click a product. The address shows its number, the card shows the detail.
Use the ← arrow in the address bar. You go back to the list – the history works like in a real browser.
Click Broken link. No route matches, so * takes over and a 404 appears.

The takeaway: Every screen has its address, the layout doesn't change and only the content in <Outlet /> changes. And all without reloading the page.

Loading the interactive part…

API	What for
`<Link to>`	Navigation without reloading the page. Relative paths are resolved against the current route.
`<NavLink>`	A Link that knows it’s active (menus, tabs).
`<Outlet />`	The place in a layout where a nested route renders.
`useParams()`	The variable parts of the address (:id). Always text – convert them!
`useNavigate()`	Navigation from code (after submitting a form, after signing in).
`<Navigate to replace />`	A redirect during render (protected pages).
`useLocation()`	The current address: pathname, search, state.

2. State in the address: search params

When you book a hotel room "with a sea view and a cot", you want that to still hold tomorrow, and you want a colleague you send the booking to to get the same. So the requests belong in the booking, not in your head.

Filters, sorting, paging, a search term – these are all requests about a page's content. If they were only in useState, they would disappear after a reload and a colleague opening the link would see something else. So they belong in the search params – the part of the address after the question mark: /products?category=fruit&sort=price.

function Catalog() {
  const [searchParams, setSearchParams] = useSearchParams()

  // Reading: like from a map, a missing value is null
  const category = searchParams.get('category')            // "fruit" | null
  const sort = searchParams.get('sort') ?? 'name'

  // Writing: changes the address → the component re-renders with the new values
  function setCategory(value: string | null) {
    setSearchParams((prev) => {
      const next = new URLSearchParams(prev)
      if (value) next.set('category', value)
      else next.delete('category')
      return next
    })
  }

  const visible = products.filter((p) => !category || p.category === category)
  // …
}

useSearchParams works much like useState: it returns the current values and a function to change them. Only the "notebook" is the address.
On a change we copy the previous parameters (new URLSearchParams(prev)) and change just one – the other requests stay.
The visible products are calculated from the address, they aren't stored anywhere. Derived state from the lesson on state.

Demo

A filtered catalogue with useSearchParams

What you see: A catalogue with a search, categories and sorting. All three filters live only in the address – watch the address bar at the top. The demo starts at the address /?category=fruit, as if someone had sent it to you.

Try it:

Notice that fruit is already selected – it came from the address.
Pick vegetables and the sorting By price. The address shows both parameters.
Click the ← arrow in the address bar. The previous filter comes back – every category change is a step in the history.
Type something into the search. The q parameter changes with every letter, but it doesn't clutter the history (the code uses replace).

The takeaway: State in the address survives a reload, can be sent as a link and works with the Back and Forward buttons. The component just reads it and calculates from it.

Loading the interactive part…

3. Loaders: a room prepared in advance

In a bad hotel they send you to your room and the housekeeper starts cleaning only when you walk in. You wait in the doorway. In a good hotel the room is ready before you walk in.

Without a loader, a component loads data itself – in an effect, only once it has rendered. The user first sees an empty page with "Loading…", and when the page has nested parts, each starts loading only after its parent (a so-called waterfall). A loader is the housekeeper: the router calls it before rendering the page and the component gets the data ready.

// The housekeeper: loads the data before the page shows
async function productLoader({ params }: LoaderFunctionArgs) {
  const product = await fetchProduct(Number(params.id))
  if (!product) throw new Response('Product not found', { status: 404 })
  return { product }
}

// The route: we assign the room a housekeeper and a "receptionist for problems"
{ path: 'product/:id', loader: productLoader, element: <ProductPage />, errorElement: <ErrorPage /> }

// The component: no useEffect, no "Loading…" – the data is already there
function ProductPage() {
  const { product } = useLoaderData<typeof productLoader>()
  return <h2>{product.name}</h2>
}

What happens after clicking a link to a product:

The router recognises the target route and calls its loader. The old page stays visible for now.
While waiting, useNavigation().state equals 'loading' – you can show a progress indicator.
The loader finishes → the router switches the address and the page at once, and the component takes the data with useLoaderData.
When the loader throws an error (say a Response with 404), the errorElement renders instead of the page – the reception says "we don't have a room like that".

Demo

Loaders, useNavigation and errorElement

What you see: A product list and a detail, both with a loader. The fake API replies with a delay. During navigation "Loading the next page…" appears above the card.

Try it:

Click a product. The list stays visible, fades and a loading message appears. Then the address and the content switch at once.
Click ← Back and pick another product. The detail never shows an empty "Loading…" – the data arrives with it.
Click A product that doesn't exist. The loader throws a 404 and an error page shows instead of the detail.

The takeaway: The data is loaded before rendering. The component only handles the display, and errorElement takes care of errors.

Loading the interactive part…

React Router mode	What it is	When
Declarative	<BrowserRouter> + <Routes>/<Route> in JSX	Simple apps, gradual migration.
Data	createBrowserRouter + loader/action/errorElement	SPAs where you want data loading tied to routes.
Framework	A Vite plugin, file-based routes, SSR, typegen	New full-stack apps (the successor of Remix).

4. Protected pages: a doorman at the VIP floor

You can't just walk onto a hotel's VIP floor – there's a doorman by the lift. If you don't have a key card, they send you to the reception, which notes down where you wanted to go. Once that's sorted, they send you straight there.

In the router, the doorman is a layout route without its own address. It wraps the protected pages and decides whether to let you through (<Outlet />) or redirect you to sign in:

function RequireAuth() {
  const { user } = useAuth()
  const location = useLocation()
  if (!user) {
    // to the reception – and note down where the guest wanted to go
    return <Navigate to={`/login?redirect=${location.pathname}`} replace />
  }
  return <Outlet />                                    // let them through
}

// A route without a path: adds nothing to the address, just wraps its children
{ element: <RequireAuth />, children: [
  { path: 'account', element: <Account /> },
  { path: 'account/settings', element: <Settings /> },
]}

replace makes sure the redirect isn't written into the history – the Back button then doesn't lead to the doorman again. Finishing the sign-in with a return to where the user wanted to go is the task of the second challenge.

Check yourself

Quiz A user filters products by category. Where should the selected category be stored?

useState in the list componentIn the address (search params)In localStorageIn Context

Quiz What does useParams().id return for the address /products/42?

the number 42the text "42"undefined{ id: 42 }

Quiz What happens when you use <a href='/products'> instead of <Link to='/products'> in an app with a router?

Nothing, it’s the sameThe browser reloads the page – the app loads again and all its state is lostThe link won’t work

Warm-up

Challenge

A link to the second page

Warm-up

Two pages, two links. Watch how the address at the top changes.

Task is in the comments in the code below – at the top of the file and at the places marked TODO.

Loading the interactive part…

I'm done

Challenges

The mini e-shop practises sections 1 and 2: a layout, a list, a detail, a filter in the address and a 404. The protected pages complete section 4 – the doorman and the return to where the user originally wanted to go.

Challenge

A mini e-shop

MediumBonus · free after sign-in

The complete routing of a small app: a layout, a list, a detail, state in the address and a 404. What should happen is in the comments in the code.

🔓 Bonus challenge – free after sign-in

Medium and hard challenges unlock once you sign in. Like the whole course, they are free – just an e-mail, no password and no payment.

Challenge

Protected pages

MediumBonus · free after sign-in

A pattern you'll find in every app with sign-in: a doorman + a return to where the user originally wanted to go. What should happen is in the comments in the code.

🔓 Bonus challenge – free after sign-in

Medium and hard challenges unlock once you sign in. Like the whole course, they are free – just an e-mail, no password and no payment.

Summary

The router is the reception: it renders the right page by the address without a reload. Nested routes + <Outlet /> = a shared layout.
Navigation: Link/NavLink in JSX, useNavigate in handlers, <Navigate /> during render. Never <a href>.
Parameters from the address are text. Filters, sorting and paging belong in search params.
A loader is the housekeeper: it prepares the data before rendering; errorElement handles errors and 404s.
Protected pages: a layout route without a path as the doorman, <Navigate replace> to the sign-in and back again.

Loading lesson…

💬 Found a mistake, something unclear, or have an idea? Let me know.