Build interactive interfaces with React components, props, state, effects, context, routing and component tests.

React Fundamentals

## Why it matters

Real apps have many screens: a home page, a product page, a settings page. Users expect each one to have its own URL that they can bookmark, share and reach with the back button. **Routing** maps URLs to the components that render them. React itself has no router, so you will use a library (React Router) or a framework (Next.js) for it.

## Multi-page apps and single-page apps

In a traditional site, every link asks the server for a new HTML page. In a **single-page application (SPA)** the browser loads the app once; when you click a link, JavaScript changes the URL with the History API and swaps the components on screen without a full reload. That is faster for users and keeps state (such as a half-filled form in a sidebar) alive.

The cost: the app must handle URLs itself, and the server must send the app's HTML for any path the user might load directly (`/products/42`), or refreshing that page gives a 404. Hosts such as Netlify and Vercel have settings for this.

## React Router

React Router is the most widely used routing library for client-side React apps. A typical setup (version 6 or 7, "declarative" mode):

```jsx
import { BrowserRouter, Routes, Route, Link, useParams } from "react-router";

function App() {
  return (
    <BrowserRouter>
      <nav>
        <Link to="/">Home</Link> <Link to="/products">Products</Link>
      </nav>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/products" element={<ProductList />} />
        <Route path="/products/:id" element={<ProductPage />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </BrowserRouter>
  );
}

function ProductPage() {
  const { id } = useParams(); // "42" for /products/42
  return <h1>Product {id}</h1>;
}
```

(In version 6 the imports come from `react-router-dom`; version 7 merged it into `react-router`. Check the docs for the version your project uses.)

The ideas to know:

- **`<Route path element>`** maps a URL pattern to a component.
- **Dynamic segments** such as `:id` match any value and are read with `useParams()`. Params are always strings: convert with `Number(id)` if needed.
- **`path="*"`** is a catch-all for a "not found" page.
- **`<Link to>`** renders a real `<a>` tag but navigates without reloading. Do not use a plain `<a href>` for in-app links, or the whole app reloads and loses state.
- **`useNavigate()`** navigates from code, for example after saving a form: `navigate("/products/42")`.
- **Nested routes** render inside a parent layout with `<Outlet />`, so a dashboard sidebar stays while the main area changes.
- **Query strings** (`/search?q=react`) are read with `useSearchParams()`. Keeping filters in the URL makes them shareable.

## File-based routing in Next.js

Frameworks such as Next.js build the routes from your **file names** instead of a route list. With the Pages Router:

```text
pages/
  index.tsx              ->  /
  about.tsx              ->  /about
  products/index.tsx     ->  /products
  products/[id].tsx      ->  /products/42, /products/abc
  404.tsx                ->  custom not-found page
```

Each file exports a React component as its default export. Square brackets mark a dynamic segment; the page reads it with `useRouter().query.id` (or receives it in data-loading functions). Links use `next/link`:

```jsx
import Link from "next/link";

<Link href="/products/42">Widget</Link>
```

Next.js also offers the newer **App Router** (`app/` folder, with `page.tsx` files and nested `layout.tsx` files). The concepts are the same: a URL maps to a component, with dynamic segments and shared layouts. Frameworks add server rendering, so each URL can arrive as ready-made HTML, which helps speed and search engines.

## Protecting routes

Some pages need a signed-in user. In an SPA a route component can check the user (often from context) and redirect to the login page. Remember that this only hides the screen: the **API must still check permissions** on every request, because anyone can call it directly.

## Accessibility and polish

- Give each page a unique `<title>` and one `<h1>`.
- After navigation, move focus to the main heading or content so screen-reader users know the page changed.
- Show a loading state while route data loads, and a helpful 404 page for unknown URLs.

## Common mistakes

- Using `<a href>` for internal links in an SPA and losing state on every click.
- Forgetting that URL params are strings.
- Deploying an SPA without a fallback rule, so deep links 404 on refresh.
- Treating client-side route guards as security.

## Recap

- Routing maps URLs to components; SPAs change the URL without full reloads.
- React Router: `Routes`/`Route`, `:param` with `useParams`, `Link`, `useNavigate`, nested layouts with `Outlet`.
- Next.js derives routes from files; `[id]` marks a dynamic segment.
- Real protection lives on the server; client-side guards are for user experience.

## Try it

Open the Do tab and take the quiz on matching URLs to routes and choosing the right navigation tools.


Map URLs to pages with React Router or Next.js file-based routing, including dynamic segments and links.

Routing basics

Learn React Router v6 In 45 Minutes

Next.js Tutorial - 5 - Routing with Pages

## Why it matters

Tests let you change code without fear. A component test renders a component, interacts with it like a user and checks what appears on screen. Teams expect pull requests to include tests, and many technical interviews include writing one. React Testing Library (RTL) is the standard tool for this.

## The guiding principle

> The more your tests resemble the way your software is used, the more confidence they can give you.

That idea from the Testing Library docs shapes everything. Users do not see component state, prop names or CSS classes. They see text, buttons, labels and headings. So tests should find elements the way a user (or a screen reader) would, and should not reach into implementation details. A good test keeps passing when you refactor the internals, and fails when behaviour breaks.

## The tools

A typical setup in a Vite project uses **Vitest** (or Jest) to run tests, **jsdom** to simulate a browser, **@testing-library/react** to render components, **@testing-library/user-event** to simulate realistic typing and clicking, and **@testing-library/jest-dom** for readable assertions such as `toBeInTheDocument()`.

```jsx
// Counter.test.jsx
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { test, expect } from "vitest";
import Counter from "./Counter";

test("adds one when the button is clicked", async () => {
  const user = userEvent.setup();
  render(<Counter />);

  expect(screen.getByText("Count: 0")).toBeInTheDocument();

  await user.click(screen.getByRole("button", { name: "Add one" }));

  expect(screen.getByText("Count: 1")).toBeInTheDocument();
});
```

The structure is **Arrange, Act, Assert**: render the component, do something a user would do, check the result.

## Queries

Queries find elements. They come in three flavours:

| Prefix | If not found | Use for |
|---|---|---|
| `getBy...` | throws | elements that should be there now |
| `queryBy...` | returns `null` | asserting something is **absent** |
| `findBy...` | waits, then rejects | elements that appear later (after a fetch) |

Each also has an `...AllBy...` form that returns an array.

And they come in priority order. Prefer the ones at the top:

1. **`getByRole`** with a name: `getByRole("button", { name: "Save" })`, `getByRole("heading", { name: /profile/i })`, `getByRole("textbox", { name: "Email" })`. This also checks your markup is accessible: if a button has no accessible name, the test cannot find it.
2. **`getByLabelText`** for form fields.
3. **`getByText`** for non-interactive content.
4. **`getByTestId`** only when nothing else works.

`screen` is a set of queries bound to the whole document. `render` also returns queries bound to its own container, which is what the Do exercise uses so several tests can run side by side.

## Interactions and async UI

`userEvent` simulates real sequences of events: `await user.type(input, "Ada")` fires key, input and change events for each character; `await user.click(button)` includes pointer and focus events. The lower-level `fireEvent.click(el)` dispatches a single event and is fine for simple cases.

When the UI updates after a promise, wait for it:

```jsx
test("shows users after loading", async () => {
  const load = () => Promise.resolve([{ id: 1, name: "Ada" }]);
  render(<UserList load={load} />);

  expect(screen.getByText("Loading...")).toBeInTheDocument();
  expect(await screen.findByText("Ada")).toBeInTheDocument();
  expect(screen.queryByText("Loading...")).not.toBeInTheDocument();
});
```

Passing a fake `load` function keeps tests fast and offline. For components that call `fetch` directly, tools such as Mock Service Worker (MSW) intercept requests instead.

## A test must be able to fail

A test that passes no matter what is worse than no test, because it gives false confidence. Check yours by breaking the code on purpose: change `count + 1` to `count + 2`, or rename the button, and confirm the test goes red. The Do exercise does exactly this to your test.

## What to test

- What the user sees for each important state: empty, loading, error, full.
- Interactions: clicking, typing, submitting, and the results.
- Callbacks: that `onSave` was called with the right data (`vi.fn()` creates a spy).
- Edge cases that broke before (write a test with every bug fix).

What not to test: internal state values, private functions, exact CSS, or React itself. Pure logic such as reducers is easier to test directly as functions, as you did in module 2.

## Common mistakes

- Querying by class name or component internals, so tests break on harmless refactors.
- Using `getBy` to assert absence (it throws); use `queryBy` and expect `null`.
- Forgetting `await` with `findBy` or `userEvent`, so assertions run too early.
- Snapshot tests of whole pages that everyone updates without reading.

## Recap

- RTL renders components and finds elements the way users do; prefer `getByRole` with a name.
- `getBy` for present, `queryBy` for absent, `findBy` for later.
- Arrange, act, assert; use `userEvent` for realistic interactions and `await` async UI.
- Prove each test can fail by breaking the code on purpose.

## Try it

Open the Do tab to write `testCounter`, a component test that must pass on the real counter and fail on three broken ones.


Write component tests with React Testing Library that find elements like a user and fail when behaviour breaks.

Testing components

React Testing Library Tutorial #1 - Introduction

React Testing Tutorial - 18 - getByRole

Create the project with `npm create vite@latest catalog -- --template react`, run `npm install` and `npm run dev`, and open the local URL.

Sketch the components (App, SearchBar, ItemList, ItemCard) and write down which two values are state and which values are derived.

Add `src/items.js` with at least 8 items across at least 2 categories, and render them in an `ItemList` of `ItemCard` components with stable `id` keys.

Add a labelled, controlled search input and category select in `SearchBar`, with the state lifted into `App`.

Write a pure `filterItems(items, query, category)` function (trimmed, case-insensitive) and render the derived list, a result count and a 'No items match' empty state.

Install Vitest, jsdom and React Testing Library, add the `test` script and the jsdom environment with `globals: true`, and write a test that typing into the search box filters the list.

Add a second component test for the empty state and unit tests for `filterItems`; break the filter on purpose and confirm the tests fail, then fix it.

Write a README (what it does, how to run and test it, what you would add next), commit, and push to a public GitHub repository.

Optional: deploy the static build (`npm run build`, folder `dist/`) to a free hosting tier and add the link to the README.

## Why it matters

Employers hiring junior front-end and mobile developers look for evidence that you can build a small but complete feature: data, components, state, user input, an empty state and tests. A searchable catalog is a classic portfolio piece because it touches every topic in this course and is easy for a reviewer to try in a minute.

## What you will build

A product (or book, course or recipe) catalog with:

- a list of items rendered from a data array, each in a reusable card component;
- a search box that filters by name as you type, ignoring case and extra spaces;
- a category dropdown that combines with the search;
- a result count and a friendly empty state ("No items match");
- at least two component tests with React Testing Library.

## Plan the components

Sketch the screen and draw boxes around each piece, then name them:

```text
App
├── SearchBar        (controlled text input + category select)
├── ResultCount      ("4 items")
└── ItemList
    └── ItemCard     (one per item)
```

Then decide where state lives. Only two values change: the search text and the selected category. Both affect the list, so they live in `App` (lifted up) and flow down as props. The filtered list and the count are **derived**, not stored.

## Set up the project

You will run this on your own computer with Node.js installed (a current LTS version; the Vite docs list the minimum). Vite creates a React project in seconds:

```bash
npm create vite@latest catalog -- --template react
cd catalog
npm install
npm run dev
```

Open the local URL it prints. Edit `src/App.jsx` and watch it update.

## Data and filtering

Put sample data in `src/items.js`:

```javascript
export const items = [
  { id: 1, name: "Mechanical keyboard", category: "Hardware", price: 89 },
  { id: 2, name: "USB-C hub", category: "Hardware", price: 35 },
  { id: 3, name: "Code editor theme", category: "Software", price: 0 },
  { id: 4, name: "Monitor arm", category: "Hardware", price: 60 },
  { id: 5, name: "Note-taking app", category: "Software", price: 8 },
];
```

Write the filter as a plain, testable function:

```javascript
export function filterItems(items, query, category) {
  const needle = query.trim().toLowerCase();
  return items.filter(
    (item) =>
      (category === "All" || item.category === category) &&
      item.name.toLowerCase().includes(needle)
  );
}
```

And use it in `App`:

```jsx
import { useState } from "react";

export default function App() {
  const [query, setQuery] = useState("");
  const [category, setCategory] = useState("All");
  const visible = filterItems(items, query, category);

  return (
    <main>
      <h1>Catalog</h1>
      <SearchBar
        query={query}
        onQueryChange={setQuery}
        category={category}
        onCategoryChange={setCategory}
      />
      <p role="status">{visible.length} item(s)</p>
      {visible.length === 0 ? (
        <p>No items match.</p>
      ) : (
        <ItemList items={visible} />
      )}
    </main>
  );
}
```

`SearchBar` holds no state of its own: it renders an `<input>` labelled "Search" and a labelled `<select>` and calls the change functions it receives.

## Add tests

Install the testing tools:

```bash
npm install -D vitest jsdom @testing-library/react @testing-library/user-event
```

Add `"test": "vitest"` to the `scripts` in `package.json`, and in `vite.config.js` add `test: { environment: "jsdom", globals: true }` to the config object (globals lets Testing Library clean up the DOM after each test). A first test:

```jsx
// src/App.test.jsx
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { test, expect } from "vitest";
import App from "./App";

test("filters items as you type", async () => {
  const user = userEvent.setup();
  render(<App />);
  await user.type(screen.getByRole("textbox", { name: /search/i }), "usb");
  expect(screen.getByText("USB-C hub")).toBeTruthy();
  expect(screen.queryByText("Monitor arm")).toBeNull();
});
```

Add a second test for the empty state, and plain unit tests for `filterItems` (empty query, mixed case, category plus query).

## Make it portfolio-ready

- Write a short README: what it does, how to run it (`npm install`, `npm run dev`, `npm test`), and what you would add next.
- Commit as you go with clear messages, and push to a public GitHub repository.
- Optionally deploy the free static build (`npm run build` produces `dist/`) to a free hosting tier such as Netlify, Vercel or GitHub Pages, and link it from the README. Free tiers do not need paid add-ons for a static site.

## Stretch goals

- Sort by price or name (sort a **copy**).
- Keep the search in the URL (`?q=usb`) so results are shareable.
- Load the items from a JSON file with `fetch` in an effect, with loading and error states.
- Extract the filtering logic into a `useFilter` hook.

## Common mistakes

- Storing the filtered list in state and forgetting to update it.
- Inputs without labels, which also makes them hard to find in tests.
- Keys from the array index, which break when the list is filtered.
- Tests that only check that the page renders.

## Recap

- Plan components and decide where state lives before coding.
- Keep minimal state (query, category) and derive the visible list and count.
- Test behaviour the way a user experiences it, including the empty state.
- Ship with a README, commits and, optionally, a free deployment.

## Try it

Open the Do tab for the step-by-step build checklist.


Plan, build and test a filterable catalog with React, then publish it as a portfolio project.

Project: a searchable catalog

Search Filter in React JS with Search Bar in React Example

React Testing Tutorial - 16 - What to test?

Map URLs to pages with routing, test components the way users use them, and build a searchable catalog for your portfolio.