An intermediate course for learners who already know JavaScript and want to build modern user interfaces. You will learn why React describes the UI as a function of data, write JSX that turns arrays into elements, and compose reusable components with props and children. You will then model interface state with useState, build controlled forms, and gather complex updates into a reducer you can unit-test. The third module covers loading data in effects with loading and error states, extracting reusable logic into custom hooks, and sharing state with lifting and context. The last module introduces routing with React Router and Next.js, testing components with React Testing Library, and a portfolio project: a searchable, filterable catalog with tests. Every lesson has a reading, free videos and a quiz, and most have a React exercise that runs and is checked in your browser. Prerequisite: JavaScript Essentials.

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

React Fundamentals

## Why it matters

Almost every job ad for a front-end, UI or mobile developer mentions React. It is a JavaScript library for building user interfaces, created at Facebook (now Meta) and open source since 2013. React Native uses the same ideas to build iOS and Android apps, and frameworks such as Next.js are built on top of it. Learning React well means learning a way of thinking about interfaces that carries over to most modern UI tools.

## The problem React solves

With plain JavaScript you change the page step by step. Suppose a shopping page shows a cart count and a list of items. When the user adds an item you must remember every place that depends on the cart:

```javascript
// Imperative: describe HOW to change the page
cart.push(item);
document.querySelector("#cart-count").textContent = cart.length;
const li = document.createElement("li");
li.textContent = item.name;
document.querySelector("#cart-list").appendChild(li);
if (cart.length === 1) {
  document.querySelector("#empty-message").remove();
}
```

Each new feature adds more of these manual updates, and it is easy to forget one. The page and your data drift out of sync, and bugs appear such as a counter that says 3 while the list shows 2 items.

## Declarative UI

React flips the approach. You describe **what** the screen should look like for a given piece of data, and React works out the DOM changes for you:

```jsx
// Declarative: describe WHAT the page looks like for this data
function Cart({ items }) {
  if (items.length === 0) {
    return <p>Your cart is empty.</p>;
  }
  return (
    <section>
      <h2>Cart ({items.length})</h2>
      <ul>
        {items.map((item) => (
          <li key={item.id}>{item.name}</li>
        ))}
      </ul>
    </section>
  );
}
```

When `items` changes, React calls `Cart` again, compares the new result with the previous one, and updates only the parts of the real page that differ. You never write "remove the empty message" by hand: an empty cart simply returns a different description.

A useful way to say this is **UI = f(data)**: the interface is a function of your data. If the data is right, the screen is right.

## Components

The second big idea is the **component**: a reusable piece of UI written as a JavaScript function that returns markup. A page is a tree of components:

```text
App
├── Header
│   └── SearchBox
├── ProductList
│   ├── ProductCard
│   └── ProductCard
└── Cart
```

Each component owns one job, can be tested on its own, and can be reused. `ProductCard` might appear on the home page, in search results and in a "recently viewed" strip, written once. Components receive inputs called **props** (lesson 3) and can remember values over time with **state** (module 2).

## What React is and is not

- React is a **library** for the view layer. It does not include routing, data fetching or a build tool. Those come from other packages or from a framework such as Next.js or React Router (module 4).
- The markup-like syntax is **JSX**. It compiles to plain JavaScript function calls (next lesson). Browsers do not understand JSX directly, so real projects use a build tool such as Vite to compile it.
- React updates the page through **react-dom** on the web and through **react-native** on phones. The component code looks almost the same in both.

## How a React app starts

Every React web app has one entry point that connects React to a real DOM element:

```jsx
const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<App />);
```

From then on React owns everything inside `#root`. You do not reach in with `document.querySelector` to change it. You change data, and React re-renders.

In this course the exercises run in your browser: each one loads React, ReactDOM and Babel (which compiles JSX on the fly) from a CDN. That is fine for learning but slow for production, where you compile ahead of time with a tool such as Vite or a framework such as Next.js.

## Common misunderstandings

- **"React makes pages fast automatically."** React makes UI code easier to keep correct. Performance still depends on what you render and how much data you load.
- **"I must use classes."** Older code uses `class` components. Modern React uses function components with hooks such as `useState`, which is what this course teaches. You will still meet class components in older codebases.
- **"I can mix React and direct DOM edits freely."** Editing React-owned DOM by hand gets overwritten on the next render. Change the data instead.

## Recap

- Imperative code says how to change the page; declarative React code says what the page should be for the current data.
- UI = f(data): React re-runs your components when data changes and applies the minimum DOM updates.
- Apps are trees of small, reusable components that take props and may hold state.
- React is a view library; routing, data fetching and builds come from tools around it.

## Try it

Open the Do tab and answer the quiz to check you can tell declarative from imperative code.


See how declarative components keep the screen in sync with your data, and how React apps are built from them.

Why components

React in 100 Seconds

What Is React And Why You Need To Know It

## Why it matters

JSX is the syntax you will write in every React component. It looks like HTML, but it is JavaScript underneath, and a few rules follow from that. Most React beginner bugs, such as a missing `key`, `class` instead of `className` or a stray object in the markup, come from not knowing what JSX really is.

## JSX is JavaScript

This line:

```jsx
const heading = <h1 className="title">Hello, {name}!</h1>;
```

is compiled (by Babel or a similar tool) into a plain function call:

```javascript
const heading = React.createElement("h1", { className: "title" }, "Hello, ", name, "!");
```

The result is a **React element**: a small object describing what to show, not a real DOM node. React later turns the tree of elements into DOM. Because JSX is an expression, you can store it in variables, return it from functions and put it in arrays.

## The rules that follow

1. **One parent.** A component returns one element. Wrap siblings in a `<div>` or an empty **fragment** `<>...</>` that adds nothing to the page.
2. **Close every tag.** `<img />`, `<br />`, `<input />`.
3. **camelCase attributes.** `className` (not `class`), `htmlFor` (not `for`), `onClick`, `tabIndex`. Inline styles take an object: `style={{ color: "red" }}`.
4. **Curly braces hold JavaScript expressions.** `{user.name}`, `{price * 2}`, `{formatDate(d)}`. Statements such as `if` or `for` cannot go inside braces.
5. **Component names start with a capital letter.** `<BookList />` is your component; `<booklist />` would be treated as an unknown HTML tag.

## Conditional rendering

Since you cannot put `if` inside JSX, use plain JavaScript around it or an expression inside it:

```jsx
function Status({ online }) {
  if (!online) {
    return <p>Offline</p>; // early return
  }
  return <p>Online</p>;
}

// Inside JSX:
<p>{count > 0 ? `${count} new messages` : "No new messages"}</p>
{isAdmin && <button>Delete</button>}
```

Careful with `&&` and numbers: `{items.length && <List />}` renders a literal `0` when the list is empty. Write `{items.length > 0 && <List />}`.

React renders strings and numbers. It skips `null`, `undefined`, `true` and `false`, which is why `&&` works. It throws an error if you try to render a plain object such as `{user}`; render `{user.name}` instead.

## Turning data into elements

Real interfaces are mostly lists: products, messages, search results. You turn an array of data into an array of elements with `map`:

```jsx
const books = [
  { id: 1, title: "Dune", author: "Frank Herbert" },
  { id: 2, title: "Kindred", author: "Octavia E. Butler" },
];

function BookList({ books }) {
  return (
    <ul>
      {books.map((book) => (
        <li key={book.id}>
          <strong>{book.title}</strong> by {book.author}
        </li>
      ))}
    </ul>
  );
}
```

`{ books }` in the parameter list reads the `books` value passed in as `<BookList books={books} />`. That is a prop, covered fully in the next lesson.

You can also `filter` or `sort` first. Use a copy before sorting, because `sort` changes the array in place: `[...books].sort(...)`.

## Keys

Each item in a list needs a `key`: a string or number that is **unique among its siblings** and **stable** over time. React uses keys to match items between renders, so when you insert, delete or reorder items it can keep each item's DOM and state attached to the right data.

- Good keys: database IDs, slugs, anything that belongs to the item.
- Risky keys: the array index. If the list is reordered or filtered, index 0 now points at different data, and inputs or animations can attach to the wrong row. Index keys are acceptable only for static lists that never change order.
- Never generate keys during render with `Math.random()`: every render gets new keys, so React rebuilds every item.

The `key` goes on the outermost element returned from `map`, not on something inside it. React warns in the console ("Each child in a list should have a unique key prop") when one is missing.

## Common mistakes

- Returning two sibling elements without a wrapper or fragment.
- Writing `class=` or `for=`; React warns and you should use `className` and `htmlFor`.
- Forgetting to `return` inside a `map` callback with curly braces: `books.map((b) => { <li>{b.title}</li> })` returns `undefined`. Use parentheses or an explicit `return`.
- Putting the key on an inner element instead of the one `map` returns.

## Recap

- JSX compiles to `React.createElement` calls that create element objects.
- Use `{}` for expressions, `className`, closed tags and one root element (or a fragment).
- Use early returns, `? :` and `&&` for conditions.
- Use `map` to turn arrays into elements, with a stable, unique `key` on each item.

## Try it

Open the Do tab. You will finish a `BookList` component that turns an array of books into list items with keys, and shows a message when the array is empty.


Write JSX, render conditionally, and turn arrays of data into lists of elements with stable keys.

JSX and rendering

ReactJS Tutorial - 8 - JSX

React 19 Tutorial - 11 - Rendering Lists

## Why it matters

Components become useful when you can reuse them with different data. **Props** are how a parent passes data into a child, and **composition** is how you build big screens out of small, focused components instead of one huge file. Good prop design is what makes a component library such as a design system pleasant to use.

## Props are function arguments

A component is a function. Its first argument is an object holding every attribute you wrote on the JSX tag:

```jsx
function Greeting(props) {
  return <p>Hello, {props.name}! You have {props.count} messages.</p>;
}

<Greeting name="Ada" count={3} />
```

Strings can be written in quotes; anything else (numbers, booleans, arrays, objects, functions) goes in braces. Most code destructures the props object in the parameter list, often with **default values**:

```jsx
function Greeting({ name, count = 0 }) {
  return <p>Hello, {name}! You have {count} messages.</p>;
}
```

A prop written with no value, such as `<Button disabled />`, is `true`.

## Props are read-only

A component must never change its props. `props.count = 5` is a bug: the data belongs to the parent. If something needs to change over time, it becomes **state** (next module), usually in the parent, which then passes new props down. Data flows one way: from parent to child.

React components should also be **pure** with respect to their props: given the same props, return the same output, with no side effects during rendering. That predictability is what lets React re-render safely whenever it needs to.

## Passing functions as props

Children communicate back up by calling functions the parent passed in:

```jsx
function LikeButton({ liked, onToggle }) {
  return <button onClick={onToggle}>{liked ? "Unlike" : "Like"}</button>;
}

// In the parent:
<LikeButton liked={isLiked} onToggle={() => setIsLiked(!isLiked)} />
```

By convention, event-handler props are named `onSomething`, and the functions that handle them in the parent are named `handleSomething`.

## Children and composition

Whatever you put **between** a component's opening and closing tags arrives as the special `children` prop:

```jsx
function Card({ title, children }) {
  return (
    <section className="card">
      <h2>{title}</h2>
      <div className="card-body">{children}</div>
    </section>
  );
}

<Card title="Ada Lovelace">
  <p>Wrote the first published computer program.</p>
  <Badge label="Pioneer" />
</Card>
```

`Card` does not need to know what is inside it. It provides the frame (border, heading, spacing), and the caller decides the content. This is **composition**: combining general-purpose containers with specific content. It is React's main tool for reuse, preferred over inheritance.

You can also pass elements in named props when a component has more than one "slot":

```jsx
<Card title="Profile" footer={<a href="/edit">Edit profile</a>}>
  ...
</Card>
```

## Optional pieces

Render optional parts only when a prop is present:

```jsx
function Card({ title, children, footer }) {
  return (
    <section className="card">
      <h2>{title}</h2>
      <div className="card-body">{children}</div>
      {footer && <footer>{footer}</footer>}
    </section>
  );
}
```

## Building class names from props

Variants such as size or colour are usually props that choose a CSS class:

```jsx
function Badge({ label, tone = "info" }) {
  return <span className={"badge badge-" + tone}>{label}</span>;
}

<Badge label="Overdue" tone="warning" />
```

Keep the number of variant props small and their allowed values clear. A component with fifteen boolean props is a sign it should be split.

## Prop drilling

When data must pass through several components that do not use it, just to reach a deep child, that is **prop drilling**. A little is normal and easy to follow. When it gets painful, composition (passing `children` so the deep child is created higher up) or context (module 3) can help.

## Common mistakes

- Changing a prop inside the child instead of asking the parent to change it.
- Writing `count="3"` (a string) when you mean the number `count={3}`.
- Calling the handler during render: `onClick={onToggle()}` runs immediately. Pass the function: `onClick={onToggle}`.
- Spreading every prop onto a DOM element (`<div {...props}>`) and leaking unknown attributes onto the page.

## Recap

- Props are the object of attributes passed to a component; destructure them and give defaults.
- Props are read-only and flow from parent to child; children talk back by calling function props.
- `children` lets a component wrap any content; composition beats huge, all-knowing components.
- Use props to choose variants, and render optional parts only when their prop exists.

## Try it

Open the Do tab to build a `Card` with a title, children and an optional footer, plus a `Badge` with a default tone, then compose them.


Pass data into components with props, wrap content with children, and compose small components into screens.

Props and composition

React 19 Tutorial - 8 - Props

React 19 Tutorial - 9 - Props Patterns

See why React describes the UI declaratively, write JSX that turns data into elements, and compose reusable components with props and children.

Components and Props

## Why it matters

Props let a parent configure a component, but interfaces also change on their own: a counter goes up, a menu opens, a tab is selected. **State** is the data a component remembers between renders. Modelling state well, keeping just the right data in it and deriving the rest, is the single biggest factor in whether React code stays simple.

## Why a normal variable is not enough

```jsx
function Counter() {
  let count = 0;
  return <button onClick={() => { count = count + 1; }}>Clicked {count}</button>;
}
```

Clicking changes the local variable, but nothing happens on screen. Two problems: React does not know it should re-render, and even if it did, `count` would start again at 0 because the function runs from the top each time.

## useState

`useState` gives a component a value that survives re-renders, and a setter that tells React to render again:

```jsx
function Counter() {
  const [count, setCount] = React.useState(0);
  return <button onClick={() => setCount(count + 1)}>Clicked {count}</button>;
}
```

- `React.useState(0)` returns a pair: the current value and a function to replace it. Array destructuring names them. In projects with a build step you usually `import { useState } from "react"` and write `useState(0)`.
- The argument is the **initial** value, used only on the first render.
- Calling `setCount(...)` schedules a re-render. On the next render `count` holds the new value.

Each instance of a component has its own state. Two `<Counter />` elements count independently.

## State is a snapshot

Inside one render, `count` is a constant. Setting state does not change the variable immediately:

```jsx
function handleClick() {
  setCount(count + 1);
  setCount(count + 1);
  console.log(count); // still the old value
}
```

Both calls compute `count + 1` from the same snapshot, so the count goes up by one, not two. When the next value depends on the previous one, pass an **updater function**:

```jsx
setCount((c) => c + 1);
setCount((c) => c + 1); // now +2
```

React queues updaters and applies them in order. Using the updater form for "add", "toggle" and similar changes is a good habit.

## Objects and arrays: replace, do not mutate

React decides whether to re-render by checking whether you gave it a new value. If you change an object in place and pass the same object back, React may skip the update, and other code holding that object sees surprising changes. Always create a new object or array:

```jsx
const [user, setUser] = React.useState({ name: "Ada", city: "London" });

// Wrong: mutates the existing object
user.city = "Paris";
setUser(user);

// Right: copy, then change
setUser({ ...user, city: "Paris" });

const [todos, setTodos] = React.useState([]);
setTodos([...todos, newTodo]);                       // add
setTodos(todos.filter((t) => t.id !== id));          // remove
setTodos(todos.map((t) => (t.id === id ? { ...t, done: true } : t))); // update one
```

## Keep the minimum state, derive the rest

Ask of every piece of data: does it change over time, and can it be computed from something else? If it can be computed, do not store it.

```jsx
// Too much state: total can drift out of sync with items
const [items, setItems] = React.useState([]);
const [total, setTotal] = React.useState(0);

// Better: derive during render
const total = items.reduce((sum, i) => sum + i.price, 0);
```

The same goes for "is the form valid", "how many are done", "filtered list". Compute them from state each render. It is fast and can never be stale.

## Disabling controls from state

Derived values are perfect for UI rules:

```jsx
<button onClick={() => setCount((c) => c - 1)} disabled={count === 0}>
  Subtract
</button>
```

The button's `disabled` attribute is computed from `count`, so it is always right.

## The rules of hooks

`useState` is a **hook**: a function whose name starts with `use` and that hooks into React features. Hooks have two rules:

1. Call them only at the **top level** of a component (or another hook), never inside `if`, loops or nested functions.
2. Call them only from React components or custom hooks.

React matches hooks by call order, so the order must be the same on every render.

## Common mistakes

- Expecting the state variable to change right after calling the setter.
- Mutating objects or arrays in state.
- Storing derived values (totals, filtered lists) in state.
- Calling `useState` inside a condition.

## Recap

- State is per-instance memory that survives re-renders; `useState(initial)` returns `[value, setValue]`.
- Setting state schedules a new render; within a render the value is a fixed snapshot.
- Use updater functions for changes based on the previous value.
- Replace objects and arrays instead of mutating them, and derive anything you can compute.

## Try it

Open the Do tab. You will turn a static counter into one that adds, subtracts and resets with `useState`, with a Subtract button that disables itself before going below zero.


Give components memory with useState, update it safely, and derive everything else from it.

useState

Learn useState In 15 Minutes - React Hooks Explained

React State Vs Props

## Why it matters

Sign-up pages, search boxes, filters, checkout steps: most of the interaction in an app is people clicking and typing. React handles events with props such as `onClick` and `onChange`, and handles form fields with **controlled components**, where React state is the single source of truth for what is in each input.

## Handling events

Pass a function to an event prop. React calls it with an event object:

```jsx
function SaveButton() {
  function handleClick(event) {
    console.log("Saved!", event.type); // "click"
  }
  return <button onClick={handleClick}>Save</button>;
}
```

- Event props are camelCase: `onClick`, `onChange`, `onSubmit`, `onKeyDown`, `onFocus`.
- Pass the function, do not call it: `onClick={handleClick}`, not `onClick={handleClick()}`.
- To pass arguments, wrap it: `onClick={() => removeItem(item.id)}`.
- `event.preventDefault()` stops the browser's default action (following a link, submitting a form). `event.stopPropagation()` stops the event bubbling to parent elements.

React's event object wraps the browser's native event and works the same across browsers.

## Controlled inputs

In plain HTML an input keeps its own value. In React you usually keep the value in state and feed it back to the input:

```jsx
function NameField() {
  const [name, setName] = React.useState("");
  return (
    <label>
      Name
      <input value={name} onChange={(e) => setName(e.target.value)} />
    </label>
  );
}
```

This loop is the core of controlled components:

1. The input shows `value={name}`.
2. The user types; React fires `onChange` with the new text in `e.target.value`.
3. You call `setName`, React re-renders, and the input shows the new value.

If you set `value` without `onChange`, the input becomes read-only, and React warns you. Because the value lives in state, you can validate, transform (for example `e.target.value.toUpperCase()`), reset or pre-fill it easily.

In React, `onChange` fires on **every keystroke**, like the DOM `input` event, not only when the field loses focus.

## Other field types

```jsx
<textarea value={bio} onChange={(e) => setBio(e.target.value)} />

<select value={plan} onChange={(e) => setPlan(e.target.value)}>
  <option value="free">Free</option>
  <option value="pro">Pro</option>
</select>

<input
  type="checkbox"
  checked={agree}
  onChange={(e) => setAgree(e.target.checked)}
/>
```

Checkboxes use `checked` and `e.target.checked` instead of `value`.

## One object for many fields

For larger forms, keep the fields in one object and use the input's `name` to update the right key:

```jsx
const [form, setForm] = React.useState({ name: "", email: "" });

function handleChange(e) {
  const { name, value } = e.target;
  setForm((f) => ({ ...f, [name]: value }));
}

<input name="name" value={form.name} onChange={handleChange} />
<input name="email" value={form.email} onChange={handleChange} />
```

## Validation and submitting

Validation rules are derived from state, so compute them during render:

```jsx
const valid = form.name.trim() !== "" && form.email.includes("@");

function handleSubmit(e) {
  e.preventDefault(); // stay on the page
  if (!valid) return;
  onSignup({ name: form.name.trim(), email: form.email.trim() });
  setForm({ name: "", email: "" }); // clear the fields
}

return (
  <form onSubmit={handleSubmit}>
    ...
    <button type="submit" disabled={!valid}>Sign up</button>
  </form>
);
```

Using a real `<form>` with `onSubmit` is best in apps: pressing Enter submits and screen readers understand the structure. (The exercise preview on this site blocks form submission, so the Do tab uses a `type="button"` with `onClick` instead.)

Client-side checks are for a pleasant experience only. The server must validate again, because anyone can send requests without your form.

## Accessible forms

- Every input needs a label. Wrap the input in `<label>` or connect them with `htmlFor` and `id`.
- Show errors as text near the field, not just a red border, and use `role="alert"` or `role="status"` for messages that appear after an action so screen readers announce them.
- A disabled button gives no hint why. For important forms, also show what is missing.

## Uncontrolled inputs

Sometimes you only need the value at submit time. You can let the DOM keep it and read it with a ref (`React.useRef`) or `new FormData(e.target)`. That is an **uncontrolled** input. Controlled inputs are the default choice when the UI reacts to what the user types: live validation, disabling buttons, filtering a list.

## Common mistakes

- `value` without `onChange` (read-only field) or switching an input between `value={undefined}` and a string (React warns about changing from uncontrolled to controlled). Start with `""`.
- Forgetting `e.preventDefault()` in `onSubmit`, so the page reloads.
- Using `value` on a checkbox instead of `checked`.
- Trusting client-side validation as security.

## Recap

- Event props take a function; use arrow functions to pass arguments.
- Controlled inputs: `value` from state plus `onChange` that sets state.
- Derive validity from state; clear or reset by setting state.
- Label every field and announce results; validate again on the server.

## Try it

Open the Do tab to build a controlled sign-up form whose button enables only when the fields are valid, and that clears itself after a successful sign-up.


Handle clicks and typing, and build a controlled form whose state drives validation and submission.

Events and forms

Full React Tutorial #27 - Controlled Inputs (forms)

ReactJS Tutorial - 21 - Basics of Form Handling

## Why it matters

As a component grows, its event handlers multiply: add an item, remove it, change a quantity, clear the cart, apply a coupon. When each handler pokes at several `useState` values, the logic gets scattered and hard to test. A **reducer** gathers every state change into one pure function you can read top to bottom and test without rendering anything.

## The idea

A reducer takes the current state and an **action** (a plain object describing what happened) and returns the next state:

```javascript
function counterReducer(state, action) {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };
    case "decrement":
      return { count: state.count - 1 };
    case "reset":
      return { count: 0 };
    default:
      return state;
  }
}

counterReducer({ count: 2 }, { type: "increment" }); // { count: 3 }
```

The name comes from `Array.prototype.reduce`: replaying a list of actions through the reducer gives you the final state.

```javascript
const actions = [{ type: "increment" }, { type: "increment" }, { type: "decrement" }];
actions.reduce(counterReducer, { count: 0 }); // { count: 1 }
```

## Rules for reducers

1. **Pure.** Same state and action, same result. No fetching, no random numbers, no timers, no `console.log`-driven logic.
2. **Never mutate.** Return new objects and arrays. React compares references to decide whether something changed.
3. **Unknown actions return the same state object**, so nothing re-renders. (Some teams throw an error instead, to catch typos.)
4. **Actions describe what happened**, not how to change state: `{ type: "added", item }` reads better than `{ type: "setItems", items }`.

## useReducer in a component

```jsx
function Counter() {
  const [state, dispatch] = React.useReducer(counterReducer, { count: 0 });
  return (
    <div>
      <p>Count: {state.count}</p>
      <button onClick={() => dispatch({ type: "increment" })}>+</button>
      <button onClick={() => dispatch({ type: "reset" })}>Reset</button>
    </div>
  );
}
```

`useReducer(reducer, initialState)` returns the current state and a `dispatch` function. Event handlers become tiny: they just describe what happened.

## A realistic example: a shopping cart

```javascript
function cartReducer(state, action) {
  switch (action.type) {
    case "add": {
      const exists = state.items.some((i) => i.id === action.item.id);
      if (exists) {
        return {
          ...state,
          items: state.items.map((i) =>
            i.id === action.item.id ? { ...i, qty: i.qty + 1 } : i
          ),
        };
      }
      return { ...state, items: [...state.items, { ...action.item, qty: 1 }] };
    }
    case "remove":
      return { ...state, items: state.items.filter((i) => i.id !== action.id) };
    case "clear":
      return { ...state, items: [] };
    default:
      return state;
  }
}
```

The patterns to remember:

- **Add to an array:** `[...items, newItem]`.
- **Remove:** `items.filter(...)`.
- **Update one item:** `items.map((i) => (i.id === id ? { ...i, changed } : i))`.
- **Update a field of the state object:** `{ ...state, field: value }`.

Note the braces around `case "add": { ... }`. They give the `const` its own block, so two cases can each declare a variable with the same name.

## Testing a reducer

Because a reducer is a plain function, testing it needs no browser and no React:

```javascript
const start = Object.freeze({ items: [] });
const once = cartReducer(start, { type: "add", item: { id: "pen", price: 2 } });
const twice = cartReducer(once, { type: "add", item: { id: "pen", price: 2 } });

console.assert(once.items[0].qty === 1);
console.assert(twice.items.length === 1 && twice.items[0].qty === 2);
console.assert(start.items.length === 0); // unchanged
```

`Object.freeze` is a handy trick: in strict mode, any attempt to mutate the frozen state throws, so a hidden mutation bug shows up immediately. (It freezes only one level; freeze nested objects too if you want full protection.) In a real project you would write these as Vitest or Jest test cases.

## Derived values stay outside

Do not store a cart total in the reducer state; compute it:

```javascript
function cartTotal(state) {
  return state.items.reduce((sum, i) => sum + i.price * i.qty, 0);
}
```

## useState or useReducer?

| Use `useState` when | Use `useReducer` when |
|---|---|
| One or two independent values | Several values change together |
| Updates are simple (set, toggle) | Many kinds of updates |
| Logic is short | You want to unit-test transitions |

Both are fine; you can start with `useState` and switch later. Libraries such as Redux use the same reducer idea for app-wide state.

## Common mistakes

- Mutating: `state.items.push(item); return state;` returns the same reference, so React may not re-render.
- Forgetting `default: return state`, so unknown actions return `undefined` and wipe the state.
- Doing side effects (API calls) inside the reducer. Do them in event handlers or effects, then dispatch the result.

## Recap

- A reducer is `(state, action) => newState`: pure and never mutating.
- `useReducer` gives you `[state, dispatch]`; handlers dispatch action objects.
- Use spread, `map` and `filter` to build new state.
- Reducers are easy to test as plain functions; keep derived values outside them.

## Try it

Open the Do tab to write and test a cart reducer with add, remove, set-quantity and clear actions, plus a `cartTotal` helper.


Collect state changes into a pure reducer with useReducer, and test it as a plain function.

Reducers for complex state

Learn useReducer In 20 Minutes

React 19 Tutorial - 27 - useReducer Hook

Model interface state with useState, handle events and controlled forms, and gather complex updates into a testable reducer.

State and Events

## Why it matters

Rendering should be pure, but apps must talk to the outside world: load data from an API, start a timer, subscribe to a WebSocket, set the page title. `useEffect` is how a component **synchronises with something outside React** after it renders. Loading data with clear loading and error states is one of the most common tasks in front-end work.

## The shape of an effect

```jsx
React.useEffect(() => {
  // runs after React has updated the screen
  document.title = `${count} new messages`;

  return () => {
    // optional cleanup: runs before the effect runs again, and on unmount
  };
}, [count]); // dependency array
```

The dependency array controls when the effect runs:

| Dependencies | Runs |
|---|---|
| `[count]` | after the first render, then whenever `count` changes |
| `[]` | once, after the first render (on mount) |
| none | after every render (rarely what you want) |

List every prop and state value the effect reads. The React ESLint plugin (`react-hooks/exhaustive-deps`) warns when one is missing.

## Cleanup

Anything an effect starts, its cleanup should stop:

```jsx
React.useEffect(() => {
  const id = setInterval(() => setSeconds((s) => s + 1), 1000);
  return () => clearInterval(id);
}, []);
```

Without the cleanup, every remount would add another interval. In development, React's `<StrictMode>` deliberately mounts, unmounts and remounts components once to expose missing cleanups, so you may see effects run twice in development. That is expected; fix the cleanup rather than fighting it.

## Fetching data with loading and error states

A request can be pending, succeed or fail, and the UI should show each case:

```jsx
function UserList() {
  const [users, setUsers] = React.useState([]);
  const [status, setStatus] = React.useState("loading"); // "loading" | "done" | "error"

  React.useEffect(() => {
    let ignore = false;

    fetch("https://api.example.com/users")
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => {
        if (!ignore) {
          setUsers(data);
          setStatus("done");
        }
      })
      .catch(() => {
        if (!ignore) setStatus("error");
      });

    return () => {
      ignore = true;
    };
  }, []);

  if (status === "loading") return <p>Loading...</p>;
  if (status === "error") return <p role="alert">Could not load users.</p>;
  return (
    <ul>
      {users.map((u) => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );
}
```

Key points:

- **`fetch` does not reject on HTTP errors.** A 404 or 500 still resolves; check `res.ok` and throw yourself.
- **The `ignore` flag** prevents a race. If the component unmounts, or the effect re-runs because a dependency (such as a search term) changed, the cleanup marks the old request as stale so its late answer does not overwrite newer data. `AbortController` can cancel the request itself: pass `{ signal: controller.signal }` to `fetch` and call `controller.abort()` in the cleanup.
- **One status value** is clearer than separate `isLoading` and `hasError` booleans that can contradict each other.
- The effect callback itself cannot be `async` (it must return a cleanup function or nothing). Define an async function inside it and call it, or use `.then` chains as above.

## Fetching when something changes

```jsx
React.useEffect(() => {
  let ignore = false;
  setStatus("loading");
  fetch(`/api/products?q=${encodeURIComponent(query)}`)
    .then((r) => r.json())
    .then((data) => { if (!ignore) { setProducts(data); setStatus("done"); } })
    .catch(() => { if (!ignore) setStatus("error"); });
  return () => { ignore = true; };
}, [query]);
```

Each new `query` starts a request; the cleanup ignores the previous one.

## Making effects testable

Passing the data-loading function in as a prop (or importing it from a module you can mock) lets tests supply fake data, a never-ending promise or a failure. The Do exercise works this way, because the exercise preview has no network.

## You might not need an effect

Effects are for synchronising with **external** systems. You do not need one to:

- **Compute values from props or state.** Calculate them during render (`const visible = items.filter(...)`).
- **Respond to a click.** Put that logic in the event handler.
- **Reset state when a prop changes.** Give the component a `key` so React remounts it.

In larger apps, data fetching usually moves to a framework (Next.js data loading) or a library such as TanStack Query, which adds caching, retries and deduplication. They still follow the same pending/success/error model you are learning here.

## Common mistakes

- Missing dependencies, so the effect uses stale values; or an object or function created during render in the dependency list, so the effect runs every render.
- Setting state that is also a dependency, creating an infinite loop.
- Forgetting cleanup for timers, subscriptions and listeners.
- Treating any `fetch` response as success.

## Recap

- `useEffect(fn, deps)` runs after render to sync with the outside world; return a cleanup.
- Model requests as loading, success and error, and render each.
- Use an `ignore` flag or `AbortController` to drop stale responses.
- Do not use effects for derived data or for event logic.

## Try it

Open the Do tab to load users in an effect and show loading, list and error states. The checks pass in their own fake loaders, including one that fails.


Run effects after render, clean them up, and fetch data with clear loading, success and error states.

useEffect and data fetching

Learn useEffect In 13 Minutes

Full React Tutorial #19 - Handling Fetch Errors

## Why it matters

After a few components you will notice the same patterns repeating: a boolean that toggles, a search box that filters a list, a value synced to the window size. **Custom hooks** let you pull that stateful logic out of components into a function you can reuse and test, the same way you extract a helper function from repeated code.

## A custom hook is a function that uses hooks

Here is a toggle written inline:

```jsx
function Menu() {
  const [open, setOpen] = React.useState(false);
  return <button onClick={() => setOpen((o) => !o)}>{open ? "Close" : "Open"}</button>;
}
```

And as a custom hook:

```jsx
function useToggle(initial = false) {
  const [on, setOn] = React.useState(initial);
  const toggle = () => setOn((v) => !v);
  return [on, toggle];
}

function Menu() {
  const [open, toggleOpen] = useToggle();
  return <button onClick={toggleOpen}>{open ? "Close" : "Open"}</button>;
}
```

Rules and conventions:

- The name **must start with `use`**. That is how React and its lint rules know the rules of hooks apply.
- A custom hook can call `useState`, `useEffect`, `useReducer`, `useContext` and other custom hooks.
- It follows the same rules: call it at the top level of a component or another hook, never inside conditions or loops.
- It can return anything: a value, an array like `useState`, or an object.

## Hooks share logic, not state

Each component that calls `useToggle` gets its **own** independent state. Two menus using the hook do not open together. A custom hook is a way to reuse *how* state works, not a shared store. To share the same value across components you lift state up or use context (next lesson).

## Returning an array or an object

- Return an **array** when there are one or two values and callers will want their own names: `const [isOpen, toggleOpen] = useToggle();`.
- Return an **object** when there are several values: callers pick what they need by name, and you can add fields later without breaking anyone.

## A filter hook

Filtering a list by a search term appears in almost every app:

```jsx
function useFilter(items, getText) {
  const [query, setQuery] = React.useState("");
  const needle = query.trim().toLowerCase();
  const results =
    needle === ""
      ? items
      : items.filter((item) => getText(item).toLowerCase().includes(needle));
  return { query, setQuery, results };
}

function ProductSearch({ products }) {
  const { query, setQuery, results } = useFilter(products, (p) => p.name);
  return (
    <>
      <input
        aria-label="Search products"
        value={query}
        onChange={(e) => setQuery(e.target.value)}
      />
      <p>{results.length} result(s)</p>
      <ul>
        {results.map((p) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </>
  );
}
```

Notice that the hook stores only `query` in state and **derives** `results` during render. Passing `getText` makes it work for any kind of item. For very large lists you could wrap the filter in `React.useMemo(() => ..., [items, needle])` so it only recomputes when its inputs change, but measure before optimising.

## A hook with an effect

Hooks can also wrap effects, hiding the subscribe and cleanup details:

```jsx
function useWindowWidth() {
  const [width, setWidth] = React.useState(window.innerWidth);
  React.useEffect(() => {
    const onResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", onResize);
    return () => window.removeEventListener("resize", onResize);
  }, []);
  return width;
}
```

Any component can now write `const width = useWindowWidth();` without knowing about event listeners. A data-loading hook such as `useFetch(url)` that returns `{ data, status }` is another common example, built from the effect pattern in the previous lesson.

## Stable functions with useCallback

A function created inside a hook is a new function on every render. That rarely matters, but if a caller puts it in an effect's dependency list, the effect would re-run each time. `React.useCallback(fn, deps)` returns the same function until the dependencies change:

```jsx
const toggle = React.useCallback(() => setOn((v) => !v), []);
```

Using the updater form (`v => !v`) means the callback does not depend on `on`, so its dependency list can be empty.

## Testing hooks

Hooks only run inside components, so tests render a tiny component that calls the hook and exposes its result. Testing Library provides `renderHook` for exactly this. The Do exercise's checks do the same thing by hand.

## When not to make a hook

Do not wrap a single `useState` call in a hook just for the sake of it, and do not turn plain calculations into hooks. If a function does not call any hooks, make it a regular function (`formatPrice`, `sortByDate`): it can then be called anywhere, including inside loops and conditions.

## Common mistakes

- Naming the function without `use`, which hides rule-of-hooks bugs from the linter.
- Expecting two components using the same hook to share state.
- Calling a hook conditionally: `if (enabled) useToggle()`.
- Storing derived results in state inside the hook instead of computing them.

## Recap

- A custom hook is a `use...` function that calls other hooks to package stateful logic.
- Every caller gets its own state; hooks share behaviour, not data.
- Return arrays for one or two values, objects for more; derive what you can.
- Hooks can wrap effects and their cleanup; plain logic should stay a plain function.

## Try it

Open the Do tab to write `useToggle` and `useFilter`, then watch the fruit picker that uses them come to life.


Extract reusable stateful logic, such as toggles and filters, into your own use-prefixed hooks.

Custom hooks

Learn Custom Hooks In 10 Minutes

10 React Hooks Explained // Plus Build your own from Scratch

## Why it matters

Sooner or later two components that are far apart in the tree need the same data: the header shows the signed-in user and so does the comment box; a theme switch in the settings changes colours everywhere. React gives you two tools. **Lifting state up** moves state to the closest common parent. **Context** delivers a value to any component below a provider without passing it through every level.

## Lifting state up

Imagine two panels where only one may be open at a time. If each panel keeps its own `isOpen` state, they cannot coordinate. The fix is to move the state to their parent and pass it down:

```jsx
function Panel({ title, isOpen, onOpen, children }) {
  return (
    <section>
      <h3>{title}</h3>
      {isOpen ? <p>{children}</p> : <button onClick={onOpen}>Show</button>}
    </section>
  );
}

function Accordion() {
  const [openIndex, setOpenIndex] = React.useState(0);
  return (
    <>
      <Panel title="About" isOpen={openIndex === 0} onOpen={() => setOpenIndex(0)}>
        We teach coding for free.
      </Panel>
      <Panel title="Contact" isOpen={openIndex === 1} onOpen={() => setOpenIndex(1)}>
        Email us any time.
      </Panel>
    </>
  );
}
```

`Panel` is now **controlled** by its parent: it receives `isOpen` and asks for changes through `onOpen`. There is one **source of truth** for which panel is open, so the two can never disagree.

The recipe:

1. Find the components that need the data.
2. Find their closest common parent.
3. Move the state there and pass the value down as props, with functions to change it.

Lifting state is the first tool to reach for. It keeps data flow explicit and easy to trace.

## When props get tiresome: prop drilling

If the common parent is high up, you may pass a prop through many layers that do not use it:

```jsx
<App theme={theme}>
  <Layout theme={theme}>
    <Sidebar theme={theme}>
      <ThemeButton theme={theme} />
```

That is **prop drilling**. A couple of levels is fine. Ten levels, or the same value needed in dozens of places (theme, current user, language), is where context helps.

## Context in three steps

```jsx
// 1. Create a context (the argument is the default value)
const ThemeContext = React.createContext(null);

// 2. Provide a value high in the tree
function ThemeProvider({ children }) {
  const [theme, setTheme] = React.useState("light");
  const toggleTheme = () => setTheme((t) => (t === "light" ? "dark" : "light"));
  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

// 3. Read it anywhere below
function ThemeButton() {
  const { theme, toggleTheme } = React.useContext(ThemeContext);
  return <button onClick={toggleTheme}>Switch to {theme === "light" ? "dark" : "light"}</button>;
}
```

`useContext` returns the `value` of the **nearest** provider above the component. When that value changes, every component reading it re-renders. Note that the provider still uses ordinary state: context does not store anything by itself. It is a delivery mechanism for state you lifted up.

(In React 19 you can render `<ThemeContext value={...}>` directly; `<ThemeContext.Provider>` works in both 18 and 19.)

## A custom hook for the context

Wrapping `useContext` in a custom hook gives callers a nicer API and a clear error when the provider is missing:

```jsx
function useTheme() {
  const value = React.useContext(ThemeContext);
  if (value === null) {
    throw new Error("useTheme must be used inside a ThemeProvider");
  }
  return value;
}
```

Because the default value is `null`, a component rendered outside the provider fails loudly instead of silently using a fake theme.

## Multiple providers

Each provider creates its own value, and the nearest one wins. Two `ThemeProvider`s side by side keep separate themes, and a provider inside another overrides it for its subtree. That is useful for, say, a dark preview pane inside a light page.

## Good uses for context

- Theme, language and formatting preferences.
- The signed-in user and permissions.
- A shared service such as a toast or notification API.
- State that one large feature shares across its own components (a wizard, an editor).

## When not to use it

- **Data only two or three nearby components need.** Lift state up and pass props.
- **Fast-changing values used by many components**, such as a mouse position. Every consumer re-renders on each change. Split contexts so unrelated values do not update together, or use a dedicated state library.
- **Server data** (API results with caching) is often better in a data-fetching library.

If the provider's `value` is a new object every render, every consumer re-renders whenever the provider does. For heavier apps, wrap it: `const value = React.useMemo(() => ({ theme, toggleTheme }), [theme]);` (and make `toggleTheme` stable with `useCallback`).

## Common mistakes

- Calling `useContext` in a component that is not inside the provider, and getting the default value.
- Putting every piece of app state in one giant context.
- Forgetting that context still needs state in the provider to change over time.

## Recap

- Lift shared state to the closest common parent; pass values down and change functions as props.
- Context (`createContext`, a provider, `useContext`) skips the intermediate layers.
- Wrap context in a `useX` hook that throws when the provider is missing.
- Keep context for widely shared, slowly changing values.

## Try it

Open the Do tab to build a `ThemeProvider` and a `useTheme` hook so a deeply nested button can switch a panel between light and dark.


Share state between components by lifting it to a common parent, and deliver it deep in the tree with context.

Context and lifting state

Learn useContext In 13 Minutes

React 19 Tutorial - 34 - Context and useContext Hook

Load data in effects with loading and error states, extract reusable logic into custom hooks, and share state with lifting and context.

Effects and Data

## 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.

React Fundamentals

About this course

Course content

Components and Props

State and Events

Effects and Data

Building an App

Where this course leads

Next course on the path

Careers that use it