State & Events

Props are what a component is given; state is what a component remembers. Props come from the parent and the component can't change them. State belongs to the component instance, survives between renders, and changes when the component calls its setter — and every change makes React render that component again.

From my notes: props are inputs passed from a parent, immutable, and make a component dynamic; state is local to a component, can change over time, and controls its behaviour. One correction: my notes call state mutable. It changes over time, but you never mutate it — you replace it by calling the setter with a new value, and React keeps the old value untouched until the next render. Treat both props and state as read-only snapshots; the difference is who's allowed to ask for a new one.

A mental model: props are the settings someone else chose for you (like the temperature a thermostat is told to hold); state is your own memory (like how long the heater has been on). A parent can change your settings; only you can change your memory.

import { useState } from "react";

export function StepCounter({ step, label }) {
  const [count, setCount] = useState(0); // owned here, changes over time

  return (
    <button onClick={() => setCount(count + step)}>
      {label}: {count}
    </button>
  );
}

export function Settings() {
  const [step, setStep] = useState(1);
  return (
    <>
      <StepCounter step={step} label="Score" />
      <button onClick={() => setStep(10)}>Use step 10</button>
    </>
  );
}

// click Score twice     → "Score: 2"
// click "Use step 10"   → still "Score: 2" (the prop changed, the state didn't)
// click Score once more → "Score: 12"

useState is the hook that gives a function component a piece of state. You call it with an initial value and get back a pair: the current value for this render, and a setter function to request a new one. const [count, setCount] = useState(0); uses array destructuring, so you name the pair whatever you like.

Each render is a snapshot. Within one render, count is a constant — calling setCount doesn't change the variable you already have; it tells React "next time you render this component, use this new value". The mental model: a component's render is a photo, not a live video. The setter asks React to take a new photo; the one you're holding doesn't change.

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    console.log(`after setCount: ${count}`);
  }

  console.log(`render: ${count}`);
  return <button onClick={handleClick}>{count}</button>;
}

// one click logs, in order:
// render: 0
// after setCount: 0     ← still 0: this render's snapshot
// render: 1

Things to know about useState:

• The initial value is used once. On later renders the argument is ignored. That's also why copying a prop into state (useState(props.colour)) doesn't follow later prop changes (see Where state lives: a decision guide).
• Lazy initialiser: pass a function to compute an expensive initial value only once: useState(() => readDraftFromStorage()). With useState(readDraftFromStorage()) (calling it), the function runs on every render and the result is thrown away. In the test, typing three characters made the eager version call it 4 times (1 mount + 3 re-renders) and the lazy version once.
• Setting an object replaces it; it doesn't merge. setForm({ name: "Asha" }) on { name, email } leaves you with { name: "Asha" } — the email is gone (the test logs exactly that). Spread to keep the rest: setForm({ ...form, name: "Asha" }). (Class components' this.setState did merge, which is where the confusion comes from — see this.state and setState.)
• Setting the same value skips the re-render. React compares old and new with Object.is. A toggle that calls setOn(false) while already false rendered once in total across two clicks.
• The setter is stable. It's the same function on every render (the test collects it into a Set across three renders and gets size 1), so it's safe to pass down and leave out of dependency arrays.
• State is per instance and per position. Two <Counter />s have separate state, and state stays attached to a component as long as it renders at the same place in the tree with the same type and key (see The Virtual DOM and reconciliation).

When an event handler calls several setters, React doesn't re-render after each one. It queues the updates and renders once, after the handler finishes, with all of them applied. This is batching. It avoids wasted renders and, more importantly, stops the user ever seeing a half-updated screen where the name has changed but the age hasn't.

From my notes: "state updates are asynchronous and React batches them for performance." Batching, yes. "Asynchronous" is a common way to say it but it's imprecise: the setter doesn't return a promise and you can't await it. What happens is that the setter schedules a render instead of running one immediately, and the current render's variables never change (the snapshot from useState). A mental model: a waiter writing down an order. You can say "a coffee… and a croissant… and make it a large", and the kitchen gets one ticket when you're done talking, not three.

import { useState } from "react";
import { flushSync } from "react-dom";

export const renders = [];

export function Profile() {
  const [name, setName] = useState("Rohit");
  const [age, setAge] = useState(30);
  renders.push(`${name}, ${age}`);

  function inHandler() {
    setName("Asha");
    setAge(31);
  }

  function inTimeout() {
    setTimeout(() => {
      setName("Ravi");
      setAge(40);
    }, 100);
  }

  async function afterAwait() {
    await Promise.resolve();
    setName("Meera");
    setAge(25);
  }

  function withFlushSync() {
    flushSync(() => setName("Dev"));
    // the DOM already shows "Dev, 25" here
    flushSync(() => setAge(50));
  }

  // …a <p>{name}, {age}</p> and one button per handler
}

// renders recorded per click (React 19.3, createRoot):
// handler   → ["Asha, 31"]
// timeout   → ["Ravi, 40"]
// await     → ["Meera, 25"]
// flushSync → ["Dev, 25", "Dev, 50"]

A setter accepts either a value (setCount(5)) or an updater function (setCount((c) => c + 1)). With a value, you say "set it to this". With an updater, you say "whatever it is by then, compute the next one like this". React queues updater functions and runs them in order, each receiving the result of the previous one.

This matters because of closures. Every function created during a render — event handlers, timeout callbacks, effect callbacks — closes over that render's state (see Closures on the JavaScript site). If the function runs later, after the state has moved on, it still sees the old value: a stale closure. From my notes: "Closures can cause unexpected state updates, especially if you reference state variables directly in an asynchronous callback."

export function TripleCounter() {
  const [count, setCount] = useState(0);

  function addThreeWrong() {
    setCount(count + 1); // count is 0 in this render…
    setCount(count + 1); // …still 0
    setCount(count + 1); // …still 0  → queues "set to 1" three times
  }

  function addThreeRight() {
    setCount((c) => c + 1); // 0 → 1
    setCount((c) => c + 1); // 1 → 2
    setCount((c) => c + 1); // 2 → 3
  }

  // …
}

// click "+3 (value)"   → count: 1
// click "+3 (updater)" → count: 4

The example from my notes — a delayed update inside setTimeout:

export function DelayedLike({ functional }) {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setTimeout(() => {
      if (functional) setCount((prevCount) => prevCount + 1); // correctly uses the latest state
      else setCount(count + 1); // stale closure: `count` is from the render that created this handler
    }, 1000);
  };

  return <button onClick={handleClick}>Likes: {count}</button>;
}

// click three times quickly, wait 1 s:
// setCount(count + 1)               → "Likes: 1"
// setCount((prevCount) => prevCount + 1) → "Likes: 3"

function handleClick() {
  setCount(count + 5);
  setCount((c) => c * 2);
  setCount(count + 1);
}

React decides whether state changed by comparing references: it checks the new value against the old one with Object.is. For numbers and strings that compares the values. For objects and arrays it compares identity — is this the same object in memory? So if you mutate an array and pass the same array back to the setter, React sees the same reference and assumes nothing changed.

From my notes: React compares previous and current state by reference; if you mutate the state directly without creating a new reference, React won't detect the change and won't re-render. My notes also say React does a "shallow comparison" of state — that's a small mix-up worth fixing for interviews. For useState, React does not look inside the object at all; it's a single Object.is(old, new) check on the value itself. Shallow comparison (checking each top-level property) is what React.memo does with props (see React.memo).

A mental model: state is a photograph pinned to a board. React looks at whether you pinned a new photo. Drawing on the existing photo with a pen (mutation) doesn't make React look again — and worse, it changes the "old" photo React was keeping for comparison.

export function Items({ mutate }) {
  const [items, setItems] = useState([1, 2, 3]);
  const [, setTick] = useState(0);

  const addItem = (newItem) => {
    if (mutate) {
      items.push(newItem); // ❌ direct mutation
      setItems(items);     // same reference → React skips the re-render
    } else {
      setItems([...items, newItem]); // ✅ new array
    }
  };

  return (
    <>
      <p>{items.join(", ")}</p>
      <button onClick={() => addItem(items.length + 1)}>Add</button>
      <button onClick={() => setTick((t) => t + 1)}>Unrelated update</button>
    </>
  );
}

// mutate:  Add → "1, 2, 3"   Add → "1, 2, 3"   Unrelated update → "1, 2, 3, 4, 5"
// spread:  Add → "1, 2, 3, 4"

The immutable versions of everyday operations:

Nested objects need a copy at every level you change:

const [user, setUser] = useState({
  name: "John",
  age: 30,
  address: { street: "123 Main St", city: "Somewhere" },
});

const moveToAnywhere = () =>
  setUser({
    ...user,                                     // copy the top level
    address: { ...user.address, city: "Anywhere" }, // copy the level you change
  });

const [user, setUser] = useState({ name: "Rohit" });

function rename() {
  user.name = "Asha";
  setUser(user);
}

Immer is a small library that lets you write updates as if you were mutating, while it produces a correct new immutable object for you. You get a draft — a proxy of your state — and change it with normal assignments, push, delete and so on. Immer records what you changed and builds a new object that copies only the changed paths, sharing everything else with the original.

From my notes: for complex applications you can use libraries like Immutable.js or Immer; Immer lets you write code that looks like mutation but returns a new immutable object, so React re-renders correctly. (Immutable.js, with its own Map/List types, is rarely chosen today — Immer works on plain objects, which is why it won. It's also what Redux Toolkit uses inside createSlice reducers, see Redux Toolkit: createSlice and configureStore.)

The mental model: Immer gives you a tracing-paper copy to draw on. You scribble freely; when you're done, Immer produces a clean new drawing that includes your edits, and the original underneath is never touched.

The "beautiful code using Immer" from my notes, with one fix — import produce from "immer" no longer works:

import { useState } from "react";
import { produce } from "immer"; // named import — Immer 10+ has no default export

export function UserProfile() {
  const [user, setUser] = useState({
    name: "John",
    age: 30,
    address: { street: "123 Main St", city: "Somewhere" },
  });

  const updateName = () => {
    setUser(
      produce(user, (draft) => {
        draft.name = "Jane"; // looks like mutation, but Immer returns a new object
      })
    );
  };

  const updateAddress = () => {
    setUser(
      produce((draft) => {
        draft.address.city = "Anywhere"; // deep update, no spreads
      })
    );
  };

  return (
    <div>
      <h1>{user.name}</h1>
      <h2>{user.address.city}</h2>
      <button onClick={updateName}>Update Name</button>
      <button onClick={updateAddress}>Update Address</button>
    </div>
  );
}

// click both buttons → <h1>Jane</h1> <h2>Anywhere</h2>

const prev = { name: "John", address: { city: "Somewhere" }, tags: ["a"] };
const next = produce(prev, (d) => { d.name = "Jane"; });
const same = produce(prev, (d) => { d.name = "John"; });

next === prev;                // false — something changed, new root
next.address === prev.address; // true  — untouched branches are shared
next.tags === prev.tags;      // true
same === prev;                // true  — a no-op recipe returns the original
Object.isFrozen(next);        // true  — and so is next.address
next.name = "X";              // TypeError: Cannot assign to read only property 'name' of object '#<Object>'

When to reach for Immer: state that's nested two or more levels, or updates that touch arrays of objects (todos[i].done = true). For flat state, spreads are fine and one dependency fewer.

React handles DOM events through props on JSX elements, named in camelCase: onClick, onChange, onSubmit, onKeyDown, onMouseEnter. You pass a function — React calls it when the event happens, with an event object as the argument. Handlers are usually defined inside the component, so they can read props and state and call setters.

The mental model: an event handler prop is leaving your phone number, not making the call. onClick={handleClick} says "call this when clicked". onClick={handleClick()} makes the call right now, during render, and leaves its return value as the number.

export function NewsletterForm({ onSubscribe }) {
  const [email, setEmail] = useState("");
  const [log, setLog] = useState([]);

  function handleSubmit(event) {
    event.preventDefault(); // stop the browser's full-page form submission
    onSubscribe(email);
  }

  function handleTopic(topic) {
    setLog([...log, topic]);
  }

  return (
    <form onSubmit={handleSubmit} onClick={() => setLog((l) => [...l, "form clicked"])}>
      <input aria-label="email" value={email} onChange={(e) => setEmail(e.target.value)} />
      <button type="button" onClick={() => handleTopic("react")}>React</button>
      <button
        type="button"
        onClick={(e) => {
          e.stopPropagation(); // the form's onClick won't hear this one
          handleTopic("kotlin");
        }}
      >
        Kotlin
      </button>
      <button type="submit">Subscribe</button>
      <output>{log.join(", ")}</output>
    </form>
  );
}

// click React, then Kotlin → log: "react, form clicked, kotlin"
// type "r@x.io", click Subscribe → onSubscribe("r@x.io"), no page reload

Other things that differ from plain DOM code:

• return false doesn't prevent anything. In inline HTML handlers it did; in React you must call e.preventDefault(). A test with onSubmit={() => false} confirmed defaultPrevented stayed false.
• Capture phase: add Capture to the name — onClickCapture runs on the way down, before the target's onClick. For a click on a button inside a div, the order is div capture → button capture → button bubble → div bubble.
• Name handler props after what happened: a component exposes onSelect, onClose, onSubscribe; inside it, the functions are conventionally handleX.
• Defining handlers inline is fine. A new arrow function each render costs almost nothing; it only matters when passed to a memoized child, which is what useCallback is for (see useCallback).

The event your handler receives is not the browser's native event. It's a SyntheticEvent: a React wrapper with the same interface as the native one (type, target, currentTarget, preventDefault(), stopPropagation()…), plus nativeEvent if you need the original. React creates it so events behave the same way across browsers and so React can run its own propagation through the component tree.

From my notes: a synthetic event is React's wrapper around the browser's native event; React normalises the event system so events behave the same regardless of browser (older Internet Explorer behaved differently), and properties like event.target, event.type, preventDefault() and stopPropagation() are normalised everywhere. All still true. Two parts of my notes are outdated, though: React no longer uses an event pool, and its delegation no longer happens at the document.

function handleClick(event) {
  console.log(event.type); // "click"
  setTimeout(() => {
    console.log(event.type); // React 17+: "click"   (React 16 and earlier: null — the event was pooled)
  }, 1000);
}

function handleClickWithPersist(event) {
  event.persist(); // React 16: prevents pooling. React 17+: does nothing (kept so old code doesn't break)
  setTimeout(() => {
    console.log(event.type); // "click"
  }, 1000);
}

// logs in React 19.3:
// "click", "persist is function, returns undefined", "later: click", "later: click"

What a synthetic event looks like in React 19.3 — the test logged these for a click on a <span> inside a <div onClick>:

When two components need the same piece of state — one changes it, another displays it, or both must stay in sync — you move the state up to their closest common parent and pass it down as props, along with a callback to change it. That's lifting state up. Siblings can't share state directly; the parent becomes the single owner and the siblings become views of it.

From my notes: lifting state up means moving state from a child to a common parent when multiple components need to share or sync it. Why:

1. Shared state — when several children need to read or update the same state, the closest common ancestor can give it to all of them.
2. Single source of truth — the state is managed in one place, which reduces complexity and makes debugging easier.
3. Simplified data flow — React's one-way data flow (parent to child) is preserved, so the flow of data is easy to follow.

The mental model: two people editing copies of the same spreadsheet drift apart. Put one copy on a shared drive (the parent), let both read from it, and route every edit through it.

import { useState } from "react";

const BOOKS = ["Clean Code", "Refactoring", "React in Depth", "Kotlin in Action"];

export function BookSearch() {
  const [query, setQuery] = useState(""); // lifted: both children need it
  const matches = BOOKS.filter((b) => b.toLowerCase().includes(query.toLowerCase()));

  return (
    <>
      <SearchBox query={query} onQueryChange={setQuery} />
      <ResultCount count={matches.length} />
      <ResultList books={matches} />
    </>
  );
}

function SearchBox({ query, onQueryChange }) {
  return <input aria-label="search" value={query} onChange={(e) => onQueryChange(e.target.value)} />;
}

function ResultCount({ count }) {
  return <p>{count} found</p>;
}

function ResultList({ books }) {
  return <ul>{books.map((b) => <li key={b}>{b}</li>)}</ul>;
}

// type "in" → "3 found", ["Refactoring", "React in Depth", "Kotlin in Action"]

How far to lift: only to the closest common parent that needs it, not "to the top just in case". Lifting too high makes every keystroke re-render a large part of the tree and couples unrelated components. When the common parent is many levels up and the props pass through components that don't use them, that's the point to consider composition or context (see The Context API).

Form inputs keep their own value in the DOM — type into an <input> and the browser remembers the text. React gives you two ways to work with that:

• Controlled: React state is the source of truth. You pass value={state} and update the state in onChange. The input shows exactly what the state says, on every keystroke.
• Uncontrolled: the DOM is the source of truth. You give an optional starting value with defaultValue and read the current value when you need it — through a ref, or from the form with FormData on submit.

A mental model: a controlled input is a puppet — it moves only when React pulls the strings. An uncontrolled input is a pet — it does its own thing and you check on it when you need to.

The uncontrolled example from my notes, made runnable:

import { useRef, useState } from "react";

export function UncontrolledInput({ onSubmit }) {
  const inputRef = useRef(null);

  const handleSubmit = () => {
    onSubmit(inputRef.current.value); // read the DOM when you need the value
  };

  return (
    <>
      <input type="text" ref={inputRef} defaultValue="Rohit" aria-label="uncontrolled" />
      <button onClick={handleSubmit}>Submit</button>
    </>
  );
}

// type " Varma", click Submit → onSubmit("Rohit Varma")

The same field, controlled:

export function ControlledInput({ onSubmit }) {
  const [name, setName] = useState("Rohit");

  return (
    <>
      <input
        aria-label="controlled"
        value={name}
        onChange={(e) => setName(e.target.value.toUpperCase())}
      />
      <p>{name.length}/20</p>
      <button disabled={name.trim() === "" || name.length > 20} onClick={() => onSubmit(name)}>
        Submit
      </button>
    </>
  );
}

// type " varma" → the input shows "ROHIT VARMA", the counter "11/20"; clear it → Submit disabled

From my notes: controlled components are better for complex forms where you need validation or synchronisation with component state; uncontrolled components are useful for simpler scenarios with fewer state updates. I'd add: uncontrolled is also the natural fit for React 19 form actions, which read values from FormData (see Forms with React 19 actions), and <input type="file"> is always uncontrolled, because its value can't be set from code.

Most state bugs aren't about how to update state but about where it lives and whether it should exist at all. Two copies of the same information drift apart; state placed too high re-renders half the app; server data copied into component state goes stale. The single best habit is to keep the minimum state and compute everything else.

The mental model: state is the facts you can't work out from other facts. A person's birth date is a fact; their age is computed. Store the birth date; calculate the age every time you need it.

// ❌ fullName duplicates information that's already in state
export function NameFormDuplicated() {
  const [first, setFirst] = useState("Rohit");
  const [last, setLast] = useState("Varma");
  const [fullName, setFullName] = useState("Rohit Varma");

  return (
    <>
      <input aria-label="first" value={first} onChange={(e) => setFirst(e.target.value)} />
      <input
        aria-label="last"
        value={last}
        onChange={(e) => {
          setLast(e.target.value);
          setFullName(`${first} ${e.target.value}`); // remembered here…
        }}
      />
      <p>{fullName}</p>
    </>
  );
}

// ✅ derive it during render
export function NameForm() {
  const [first, setFirst] = useState("Rohit");
  const [last, setLast] = useState("Varma");
  const fullName = `${first} ${last}`;
  // …same inputs, <p>{fullName}</p>
}

// change "first" to "Asha":
// NameFormDuplicated → <p>Rohit Varma</p>   ❌ stale
// NameForm           → <p>Asha Varma</p>

The same bug in another shape — copying a prop into state:

function ColourBadge({ colour }) {
  const [current] = useState(colour); // ❌ copies the prop once
  return <span>{current}</span>;
}
// <ColourBadge colour="red" /> then <ColourBadge colour="blue" /> → still shows "red"

useState(colour) uses its argument only on the first render, so later prop changes are ignored. Use the prop directly. If the component really needs editable local state that starts from a prop (a form initialised from a saved record), name it initialColour so the intent is clear, and give the component a key to reset it when the record changes (see Rendering lists and keys).

The decision guide, top to bottom — stop at the first "yes":