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

React Fundamentals

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