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

React Fundamentals

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