React Interview Questions

TL;DR

React is an open-source library maintained by Meta and the community for building user interfaces from components. Components describe UI declaratively from props, state, and context; React reconciles those descriptions and commits the necessary changes through renderers such as React DOM and React Native. Its main benefits are composability, explicit one-way data flow, reusable stateful logic through Hooks, support for client and server rendering architectures, and a broad ecosystem.

Key characteristics of React:

• Declarative: You describe the desired UI from data, and the renderer coordinates the required host updates.
• Component-based: Build reusable and modular UI elements (components) that manage their own state and logic.
• Reconciliation: React compares element descriptions and commits the necessary renderer-specific changes. These descriptions are not a copy of the browser DOM.
• JSX: While not mandatory, JSX is a syntax extension for expressing element structure alongside JavaScript values and control flow.

What is React?

React is an open-source JavaScript library maintained by Meta and the community for building user interfaces. It can power small interactive widgets, single-page applications, native applications through React Native, and server-rendered applications through a framework. React lets developers compose components that derive their output from props, state, and context.

Modern React is function-component- and Hooks-oriented. JSX, an HTML-like syntax extension to JavaScript, is the standard way to describe UI. React 19 added stable Server Components, the use API for reading promises and context, and Actions for form and data mutations. React Compiler 1.0 is a separate, optional build-time optimizer that can memoize compatible components and values when enabled.

Benefits of React

React's benefits come from its component model, declarative rendering, renderer ecosystem, and scheduling capabilities.

1. Component-based architecture

React encourages breaking a UI into reusable components. A component can encapsulate rendering, local state, and related behavior, which supports:

• Modularity and reuse: A component with an explicit prop contract can be composed in multiple features or applications.
• Local reasoning: Keeping related rendering and behavior together narrows the code involved in many changes.
• Focused tests: Components can be exercised through their visible output and interactions at a defined boundary.

2. Declarative rendering and reconciliation

Components return React elements that describe the desired UI. React reconciles a new description with the previous one and lets the renderer commit the required host changes. This gives applications a predictable declarative update model and avoids replacing unchanged DOM nodes. It has its own rendering and diffing costs, so it is not a guarantee that React is faster than carefully written imperative DOM code.

3. Large and active community

React has a mature ecosystem, which affects practical framework and library choices:

• Maintained documentation and learning material: The official documentation covers both fundamentals and current APIs.
• Third-party libraries and tools: Established options exist for routing, data fetching, testing, forms, and accessible UI primitives.
• A large hiring and support base: Many teams already have React experience, examples, and production knowledge to draw from.

4. One-way data binding

React uses a unidirectional data flow: data is passed from parent components down to children via props, and child components request updates through callbacks rather than mutating parent state directly. This gives each value an explicit owner and update path.

5. Hooks and function components

Modern React is built around function components and Hooks. Hooks such as useState, useEffect, useReducer, useContext, and useRef provide state, synchronization, and context access without classes. Custom Hooks extract related stateful logic for reuse across components.

6. Learn once, write anywhere

React's component and state model also applies to React Native. Web and native applications can often share business logic, data hooks, and design concepts, but their host components and platform-specific interaction code usually differ.

Further reading

• React Official Website: https://react.dev/
• React Documentation: https://react.dev/learn
• React Blog: https://react.dev/blog
• React Native: https://reactnative.dev/

Exercises

TL;DR

A React Node is a value React can render, including an element, string, number, bigint, iterable of nodes, portal, or an empty value such as null or a boolean. React 19's type also supports promises that resolve to renderable nodes in supported rendering environments. A React Element is the immutable object produced by JSX or createElement that describes what to render. A React Component is a function or class React uses as an element type. Components produce nodes; elements are descriptions; nodes are the broader set of renderable values.

React node

A React Node is anything that can appear in a JSX child position. The set includes:

• React Elements (e.g. <div />, <MyComponent />)
• Strings, numbers, and bigints (rendered as text)
• Arrays and other iterables of React Nodes (arrays are commonly produced by .map(...))
• Fragments (<>...</> or <React.Fragment>)
• Portals (created with createPortal)
• Promises of React Nodes in rendering environments that support suspending on them
• null, undefined, false, and true — these are valid nodes that render nothing (they are skipped, not converted to text)

const stringNode = 'Hello, world!';
const numberNode = 123;
const arrayNode = [<li key="a">a</li>, <li key="b">b</li>];
const fragmentNode = (
  <>
    <span>one</span>
    <span>two</span>
  </>
);
const nothingNode = null; // also: undefined, false, true — render nothing
const elementNode = <div>Hello, world!</div>;

This is why condition && <Thing /> works: when condition is false, the child is just a node that renders nothing.

React element

A React Element is an immutable, plain JavaScript object that describes what should appear on screen. It includes a type (a string for host elements like 'div', or a component reference), props (including children), and a key. JSX is sugar for React.createElement (or, with the modern JSX transform, react/jsx-runtime's jsx function), which produces these objects.

const element = <div className="greeting">Hello, world!</div>;

// Roughly equivalent to:
const sameElement = React.createElement(
  'div',
  { className: 'greeting' },
  'Hello, world!',
);

React elements should be treated as opaque and immutable rather than inspected or modified directly. They are lightweight, short-lived descriptions that React reconciles with the previous output before the renderer commits host changes.

React component

A React Component is a function or class that React can use as an element type. It accepts props and returns React Nodes that describe the UI; an async Server Component may return a promise of a node. Component names are conventionally PascalCase so JSX can distinguish them from host elements (<button> is a DOM element; <Button> is a component).

• Function components are the standard form. They are plain functions of props that return a node:

  function Welcome({ name }) {
    return <h1>Hello, {name}</h1>;
  }

  Hooks (useState, useEffect, useMemo, etc.) cover what used to require a class.

• Class components remain supported, but React recommends function components for new code. Legacy lifecycles such as componentWillMount, componentWillReceiveProps, and componentWillUpdate are deprecated, and Hooks are available only in functions.

  class Welcome extends React.Component {
    render() {
      return <h1>Hello, {this.props.name}</h1>;
    }
  }

The mental model: a component is a recipe, an element is a single dish made from that recipe, and a node is anything React is willing to plate up — including "nothing."

The relationships are easiest to see by following one component invocation from JSX to renderable output:

Further reading

• React documentation: Render and commit
• React documentation: Passing Props to a Component
• React documentation: Writing Markup with JSX
• React documentation: Your First Component

Exercises

TL;DR

JSX is a syntax extension for JavaScript that lets you describe UI with HTML-like markup inside JavaScript. A build tool transforms it into ordinary function calls before the browser runs it. With the modern automatic runtime, <div>Hello, world!</div> becomes a call to a helper from react/jsx-runtime; the older classic transform used React.createElement.

What is JSX and how does it work?

JSX is syntax that a build tool transforms into calls producing React element descriptions; browsers do not execute JSX directly.

What is JSX?

JSX is a syntax extension for JavaScript that lets you describe UI trees with an HTML-like syntax. Although it was popularized by React, JSX itself is a separate spec and is also used by other libraries such as Preact and Solid. TypeScript supports it natively in .tsx files.

How does JSX work?

JSX is not valid JavaScript by itself. A compiler — typically Babel or the bundler's built-in transform (SWC, esbuild, Oxc) — converts JSX into ordinary JavaScript function calls before the browser sees it.

JSX syntax

JSX allows you to write HTML-like tags directly in your JavaScript code. For example:

const element = <h1>Hello, world!</h1>;

Transformation process

Since React 17 (2020), the default transform is the automatic JSX runtime. Instead of compiling to React.createElement, the compiler imports jsx / jsxs helpers from react/jsx-runtime and emits calls to those. A consequence is that you no longer need to import React from 'react' just to use JSX:

// Source
const element = <h1>Hello, world!</h1>;

// Output with the automatic runtime (conceptually)
import { jsx as _jsx } from 'react/jsx-runtime';
const element = _jsx('h1', { children: 'Hello, world!' });

The older "classic" transform compiled the same JSX to React.createElement('h1', null, 'Hello, world!') and required React to be in scope. The classic form is still useful as a mental model for what JSX desugars to, but new projects should use the automatic runtime.

Regardless of which transform is configured, JSX becomes ordinary JavaScript before React receives an element description:

Embedding expressions

You can embed JavaScript expressions inside JSX using curly braces {}. For example:

const name = 'John';
const element = <h1>Hello, {name}!</h1>;

Attributes in JSX

You can use quotes to specify string literals as attributes and curly braces to embed JavaScript expressions. For example:

const element = <img src={user.avatarUrl} alt="User Avatar" />;

Because JSX attributes compile to JavaScript object keys, a few HTML attribute names are renamed to avoid clashing with reserved words or to follow JS camelCase conventions:

• class becomes className
• for becomes htmlFor
• Event handlers are camelCased: onclick becomes onClick, onchange becomes onChange
• Most other DOM properties (tabIndex, readOnly, maxLength, etc.) use camelCase

Fragments

To return multiple elements without an extra wrapper DOM node, use a fragment. The shorthand syntax is <>...</>:

function List() {
  return (
    <>
      <li>One</li>
      <li>Two</li>
    </>
  );
}

The longer form <Fragment key={id}>...</Fragment> is needed when you must pass a key.

JSX is an expression

After compilation, JSX expressions become regular JavaScript function calls and evaluate to JavaScript objects. This means you can use JSX inside if statements, assign it to variables, and pass it as a prop or argument.

JSX prevents injection attacks

By default, React DOM escapes any values embedded in JSX with {} before rendering them, which neutralizes the most common XSS vector — injecting markup via untrusted strings:

const userInput = '<img src=x onerror="alert(1)" />';
const safe = <div>{userInput}</div>; // rendered as text, not as HTML

This protection is not absolute. Two notable escape hatches still bypass escaping and can introduce XSS if fed untrusted data:

• dangerouslySetInnerHTML={{ __html: ... }} injects raw HTML into the DOM.
• React 19 blocks javascript: URLs in URL-valued attributes such as href and src. You should still validate attacker-controlled URLs against the schemes and destinations your application permits because other schemes, redirects, and resource types can carry their own risks.

Further reading

• React: Writing markup with JSX
• React: Introducing the new JSX transform
• React 19 upgrade guide: javascript: URLs
• Babel

Exercises

TL;DR

State is data a component owns and can update over time; props are data a component receives from its parent and must treat as read-only. A state update schedules the owning component to render again unless React can apply a same-value bailout; descendants render by default but may also bail out. New props arrive when the parent renders new element descriptions. Together they implement React's one-way data flow: state lives at the lowest common ancestor that needs it, flows down as props, and changes flow back up via callbacks passed as props.

What is the difference between state and props in React?

State is component-owned memory, while props are read-only inputs supplied by the component's parent.

State

State is data a component owns and can change over time, usually in response to user interaction, network responses, or timers. When state changes, React schedules a re-render of that component so the UI reflects the new value.

• State is local: a parent cannot read a child's state directly.
• In function components, state is declared with the useState hook (or useReducer for more complex transitions).
• Setters queue state for a subsequent render and React batches updates where possible. The current handler still sees the state snapshot from the render that created it.
• The term updater function specifically refers to the setX(prev => next) form passed to a setter — not the setter itself. Use it whenever the next value depends on the previous one, so batched updates compose correctly.

import { useState } from 'react';

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

  // This works for one click, but repeated queued calls would reuse the same
  // render snapshot: const increment = () => setCount(count + 1);

  // Right: the updater function gets the latest value
  const increment = () => setCount((prev) => prev + 1);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
      <button
        onClick={() => {
          // Both updates apply; final count goes up by 2
          increment();
          increment();
        }}>
        Increment twice
      </button>
    </div>
  );
}

Props

Props (short for "properties") are the inputs a parent passes to a child. From the child's perspective they are read-only — you must not assign to them. From the system's perspective they are not "immutable" in any deep sense; the parent simply re-renders with a new value, and the child receives the new props on its next render.

function Parent() {
  const [name, setName] = useState('World');
  return (
    <>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <Greeting message={`Hello, ${name}!`} />
    </>
  );
}

function Greeting({ message }) {
  // Read-only here. Mutating `message` would be a bug.
  return <p>{message}</p>;
}

Props can carry data, JSX (children), and callbacks. Callback props are how children communicate upward — the child invokes the function, the parent updates its state, and new props flow down on the next render.

One-way data flow, lifted state, and derived values

These three ideas tie state and props together:

• One-way data flow. Data moves down the tree as props. To affect a parent, a child calls a function the parent passed in. There is no two-way binding.
• Lifting state up. When two siblings need the same data, move the useState to their nearest common ancestor and pass the value (and a setter) down as props. This keeps a single source of truth.
• Derived state vs state. Anything you can compute from props or existing state during render should be computed, not stored. Storing a derived value duplicates the source of truth and creates sync bugs; just calculate it in the render body (and reach for useMemo only if the computation is expensive).

function Cart({ items }) {
  // Derived from props — do NOT put this in useState
  const total = items.reduce((sum, item) => sum + item.price, 0);
  return <p>Total: {total}</p>;
}

Key differences

The following table compares ownership, updates, and rendering behavior:

Further reading

• React documentation: State — A component's memory
• React documentation: Passing props to a component
• React documentation: Sharing state between components (lifting state up)
• React documentation: Queueing a series of state updates (batching and updaters)
• React documentation: Choosing the state structure (avoiding redundant/derived state)

Exercises

TL;DR

The key prop tells React how to identify each child in a list across renders so it can match the right component instance to the right data, preserve its state, and reorder DOM nodes correctly. A key only needs to be unique among siblings, not globally. Changing a component's key is also the idiomatic way to reset its state — React unmounts the old instance and mounts a fresh one.

<ul>
  {items.map((item) => (
    <ListItem key={item.id} value={item.value} />
  ))}
</ul>

What is the purpose of the key prop in React?

Keys give sibling elements stable identity so reconciliation can preserve or reset the correct component state and DOM.

Introduction

The key prop is a special attribute you need to include when creating lists of elements in React. It is crucial for helping React identify which items have changed, been added, or removed, thereby optimizing the rendering process.

Why key is important

Stable identity affects correctness before it affects rendering efficiency:

1. Correct identity during reconciliation: When React diffs a list, the key is how it decides which previous element corresponds to which new one. Without keys (or with bad keys) React can still render the list, but it will associate the wrong component instance with the wrong data — which means the wrong internal state, refs, and DOM nodes get reused. The bigger risk is incorrect state association, not raw DOM operation count.
2. Efficient reordering: With stable keys, React can move existing DOM nodes instead of unmounting and remounting them when items are reordered.
3. Explicit state reset: Changing a component's key deliberately is the idiomatic way to force React to unmount the old instance and mount a brand-new one (see Resetting state with a key below).

How to use the key prop

When rendering a list of elements, you should provide a unique key for each element. This key should be stable, meaning it should not change between renders. Typically, you can use a unique identifier from your data, such as an id.

const items = [
  { id: 1, value: 'Item 1' },
  { id: 2, value: 'Item 2' },
  { id: 3, value: 'Item 3' },
];

function ItemList() {
  return (
    <ul>
      {items.map((item) => (
        <ListItem key={item.id} value={item.value} />
      ))}
    </ul>
  );
}

function ListItem({ value }) {
  return <li>{value}</li>;
}

Rules for keys

A useful key must remain tied to the same logical sibling across renders:

• Unique among siblings, not globally: Keys only need to be unique within a single map() / array. Two unrelated lists can happily both contain a key="1".
• Stable across renders: The same piece of data should get the same key every render. Avoid Math.random() or Date.now().
• Keys are not passed to the child: key is consumed by React itself. If your child component also needs the id, pass it as a separate prop.

Keys on Fragments

When you render a list of fragments, you cannot use the <>...</> shorthand because it does not accept props. Use the long-form <Fragment key={...}> instead:

import { Fragment } from 'react';

function Glossary({ entries }) {
  return (
    <dl>
      {entries.map((entry) => (
        <Fragment key={entry.term}>
          <dt>{entry.term}</dt>
          <dd>{entry.definition}</dd>
        </Fragment>
      ))}
    </dl>
  );
}

Common mistakes

Most key bugs come from deriving identity from render position or generating a new identity during render:

1. Using array index as key for dynamic lists: If the list can be reordered, filtered, or have items inserted in the middle, using the index causes React to associate the wrong state with the wrong item — a classic cause of "the input I typed into moved to the wrong row" bugs. Index-as-key is acceptable only for static, append-only lists that never reorder.
2. Non-unique keys: Duplicate keys among siblings trigger a warning and cause React to mis-match items during reconciliation.
3. Generating a new key every render: key={Math.random()} forces every item to remount on every render — killing performance and wiping state.

function BadList({ items }) {
  return (
    <ul>
      {items.map((item, index) => (
        <ListItem key={index} value={item.value} />
      ))}
    </ul>
  );
}

function GoodList({ items }) {
  return (
    <ul>
      {items.map((item) => (
        <ListItem key={item.id} value={item.value} />
      ))}
    </ul>
  );
}

Resetting state with a key

Because React treats a component with a new key as a different instance, changing the key unmounts the old component and mounts a new one — resetting all of its state, refs, and effects. This is the idiomatic way to reset a form or other stateful subtree when some identifier changes:

function ProfileEditor({ userId }) {
  // When userId changes, the Form unmounts and a fresh one mounts with
  // pristine local state — no manual reset logic needed.
  return <Form key={userId} userId={userId} />;
}

Further reading

• React documentation on keys
• React documentation: keeping list items in order with key
• Preserving and Resetting State in React

Exercises

TL;DR

Using array indices as keys causes React to reconcile the list incorrectly when items are reordered, inserted, or removed. Because the key identifies a position rather than an item, React reuses the wrong component instances — leaving stale local state, focus, and DOM attached to the wrong rows. The fix is to use a stable, unique identifier from the data (e.g. item.id). Index keys are only safe when the list is static and never reordered, filtered, or prepended to.

Consequence of using array indices as the value for keys in React

An index identifies a list position rather than the logical item occupying it, which breaks identity when the list changes before that position.

Incorrect reconciliation, not just "slow renders"

The real problem is correctness, not performance. React's key is the identity React uses to match an element across renders. When the key is the array index, the identity tracks the slot in the array rather than the item in the slot. After a reorder, insert, or delete, React still matches key={0} to key={0}, so it:

• Keeps the same component instance mounted for what is now a different item.
• Preserves local useState, refs, focus, scroll position, and uncontrolled input values on the wrong row.
• Skips bailouts it would otherwise hit, because props for the reused instance changed.

In other words, the bug is "state and DOM tied to the wrong items." Re-render cost is a secondary consequence.

The classic input/checkbox state-bleed bug

This is the canonical demonstration. Each row owns an uncontrolled <input>; the user types into the second one, then the list is reordered or the first item is deleted.

function TodoList({ todos, onDelete }) {
  return (
    <ul>
      {todos.map((todo, index) => (
        // Bug: key is the index
        <li key={index}>
          <input type="checkbox" defaultChecked={todo.done} />
          <input type="text" defaultValue={todo.title} />
          <button onClick={() => onDelete(todo.id)}>Delete</button>
        </li>
      ))}
    </ul>
  );
}

If the user checks the second row and then deletes the first row, React reuses the old <li key={0}> for the item that moved into index 0. That item therefore inherits the first row's uncontrolled DOM state. The checked DOM from the old <li key={1}> either moves to the item now at index 1 or disappears if no row remains there. Switching to key={todo.id} fixes the mismatch because React removes only the deleted item's row and preserves each surviving item's DOM with that item.

The two key strategies give React different answers about which row survived the deletion:

When index keys are acceptable

Index keys are fine when all of the following hold:

• The list is static (never reordered or filtered).
• Items are never inserted or removed from anywhere except the end.
• Each item has no per-row state, focus, or uncontrolled input that could leak.

A render-once nav menu built from a constant array fits. A live, editable, sortable, or paginated list does not.

Omitting the key is even worse

If you leave key off entirely, React falls back to using the index and prints a Warning: Each child in a list should have a unique "key" prop in development. Suppressing the warning by passing key={index} does not fix the underlying issue — it just hides the message.

Better approach

Use a stable id that comes from the data, not from the render position.

const items = [
  { id: 'a1', name: 'Item 1' },
  { id: 'b2', name: 'Item 2' },
  { id: 'c3', name: 'Item 3' },
];

const List = () => (
  <ul>
    {items.map((item) => (
      <li key={item.id}>{item.name}</li>
    ))}
  </ul>
);

If the data has no natural id, generate one when the item is created (e.g. crypto.randomUUID()) and store it on the item — do not generate a fresh id inside map, because it would change every render and defeat reconciliation entirely.

Further reading

• React documentation on keys
• React documentation: keeping list items in order with key
• React performance optimization with keys

Exercises

TL;DR

A controlled component drives a form input from React state — you pass value/checked plus an onChange handler, and React state is the single source of truth. An uncontrolled component lets the DOM keep the value; you read it via a ref (or on submit) and seed the initial value with defaultValue/defaultChecked. Controlled inputs are the right default when you need validation, conditional UI, or to derive other state from the value. Uncontrolled inputs are simpler for write-once forms and for <input type="file">, which is always uncontrolled. React 19 also added first-class form support via the form action prop, useFormStatus, and useActionState, which often removes the need for per-field controlled state.

What is the difference between controlled and uncontrolled React components?

The distinction is which system owns the current form value: React state for a controlled input or the DOM for an uncontrolled input.

Controlled components

A controlled input passes both value (or checked) and onChange to the element. React state holds the truth; every keystroke flows through a setter.

import { useState } from 'react';

function ControlledForm() {
  const [name, setName] = useState('');

  function handleSubmit(event) {
    event.preventDefault();
    alert('A name was submitted: ' + name);
  }

  return (
    <form onSubmit={handleSubmit}>
      <label>
        Name:
        <input
          type="text"
          value={name}
          onChange={(event) => setName(event.target.value)}
        />
      </label>
      <input type="submit" value="Submit" />
    </form>
  );
}

Uncontrolled components

An uncontrolled input keeps its value in the DOM. Seed the initial value with defaultValue (or defaultChecked for checkboxes/radios), and read the current value through a ref when you need it.

import { useRef } from 'react';

function UncontrolledForm() {
  const inputRef = useRef(null);

  function handleSubmit(event) {
    event.preventDefault();
    alert('A name was submitted: ' + inputRef.current.value);
  }

  return (
    <form onSubmit={handleSubmit}>
      <label>
        Name:
        <input type="text" defaultValue="" ref={inputRef} />
      </label>
      <input type="submit" value="Submit" />
    </form>
  );
}

defaultValue is only consulted on the initial render — changing it later does not update the DOM. Passing value without an onChange handler makes the input read-only and warns in development unless readOnly is intentional. The reverse is valid: an input with onChange but no value remains uncontrolled. Pick one mode per field and do not switch modes during the input's lifetime.

<input type="file"> is always uncontrolled

File inputs cannot be controlled — their value is read-only for security reasons (a page must not be able to set the user's chosen file). Always read files via a ref or from the change/submit event, even in an otherwise controlled form.

function FileForm() {
  const fileRef = useRef(null);

  function handleSubmit(event) {
    event.preventDefault();
    const file = fileRef.current.files[0];
    // upload file...
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="file" ref={fileRef} />
      <button type="submit">Upload</button>
    </form>
  );
}

React 19 form actions

React 19 made <form action={...}> a first-class way to handle submissions without per-field controlled state. The action receives a FormData object, and useFormStatus / useActionState expose pending and result state.

import { useActionState } from 'react';
import { useFormStatus } from 'react-dom';

function SubmitButton() {
  const { pending } = useFormStatus();
  return <button disabled={pending}>{pending ? 'Saving...' : 'Save'}</button>;
}

async function saveName(_previousState, formData) {
  const name = String(formData.get('name') ?? '');
  const response = await fetch('/api/profile', {
    method: 'POST',
    body: formData,
  });
  if (!response.ok) return { ok: false, error: 'Could not save name.' };
  return { ok: true, name };
}

function NameForm() {
  const [state, formAction] = useActionState(saveName, null);
  return (
    <form action={formAction}>
      <input name="name" defaultValue={state?.name ?? ''} />
      <SubmitButton />
      {state?.error && <p role="alert">{state.error}</p>}
    </form>
  );
}

This pattern uses uncontrolled inputs (defaultValue plus name) and reads them out of FormData in the action — often the simplest choice for plain submit-style forms.

Key differences

The ownership choice changes how values update and which use cases each style fits.

State management

Controlled and uncontrolled inputs store their current value in different places:

• Controlled: React state owns the value; the DOM mirrors it.
• Uncontrolled: The DOM owns the value; React reads it on demand.

Data flow

Both styles can report changes, but only the controlled style feeds every rendered value back through React state:

• Controlled: state -> value -> input, and onChange -> setState.
• Uncontrolled: defaultValue -> input, then ref.current.value (or FormData) when read.

The controlled loop continuously routes the value through React, while the uncontrolled path leaves ongoing ownership in the DOM:

When to use which

Choose according to whether application logic must observe or transform each value change:

• Controlled: validation as the user types, conditional disabling, formatting, deriving other state, or anything that needs to react to every keystroke.
• Uncontrolled: simple submit-once forms, integration with non-React code, file inputs, and forms built around React 19 actions.

Further reading

• React documentation on <input> controlled vs uncontrolled
• React documentation on manipulating the DOM with refs
• React documentation on <form> with actions
• React documentation on useActionState
• React documentation on useFormStatus

Exercises

TL;DR

Context in React is convenient but easy to misuse. The biggest pitfalls are passing a fresh object or array as the provider value on every render, assuming memo or React Compiler will stop a context subscription update (they won't), and putting frequently changing, unrelated data into one context. Split independent values into focused providers, stabilize object values when appropriate, and consider a selector-based state library when consumers need different slices of rapidly changing state.

Pitfalls of using context in React

Context is convenient for distribution, but its broadcast update model and implicit dependencies can become costly when a value changes frequently or grows too broad.

Unnecessary re-renders from an unstable provider value

When a context value changes by reference, every component that reads that context re-renders — even if it only uses a field that hasn't actually changed. The most common cause is constructing a new object inline as the provider's value, which makes a fresh reference on every parent render:

// Pitfall — `value` is a new object every render, so every consumer re-renders
function ParentComponent() {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');

  return (
    <MyContext.Provider value={{ user, setUser, theme, setTheme }}>
      <ChildComponent />
    </MyContext.Provider>
  );
}

Fix it by memoizing the value. React Compiler may generate equivalent memoization when enabled, but Context still propagates every genuine value change:

function ParentComponent() {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');

  const value = useMemo(
    () => ({ user, setUser, theme, setTheme }),
    [user, theme],
  );

  return (
    <MyContext.Provider value={value}>
      <ChildComponent />
    </MyContext.Provider>
  );
}

Note: only consumers of the context re-render when the value changes — not "all components in the subtree." Components that don't call useContext/use(MyContext) are unaffected.

React.memo doesn't stop context-driven re-renders

A common surprise: wrapping a consumer in React.memo does not prevent re-renders triggered by a context value change. memo only skips re-renders caused by changing props. If the component reads a context whose value changed, it re-renders regardless. The fix is to make the context value stable (above) or split the context.

Putting too much unrelated state in one context

If you cram an entire app's state into a single context, every change to any slice re-renders every consumer. Split it into smaller, focused providers — for example, separate AuthContext, ThemeContext, and CartContext — so that a cart update doesn't re-render every theme consumer. You can also split read and write APIs into separate contexts so components that only need to dispatch don't re-render when state changes.

No built-in selectors

Unlike Redux's useSelector, React context has no built-in way to subscribe to a slice of the value. Any change to the value re-runs every consumer. Workarounds include:

• Splitting the context into smaller pieces (preferred).
• The community use-context-selector library, which adds selector-based subscriptions.

Using context as a state manager

Context transports a value through a subtree; pairing it with useState or useReducer can be a reasonable state solution for a small application. Context does not add caching, middleware, devtools, or selector-based subscriptions by itself. Consider Redux Toolkit, Zustand, or Jotai when those capabilities solve a concrete client-state problem. Fetched data can be passed through context, but a framework data layer or a library such as TanStack Query, SWR, or RTK Query is usually a better fit when it needs caching, deduplication, invalidation, or background refetching.

Debugging difficulties

Because context updates can fan out across the tree, tracking down which provider caused a re-render can be hard, especially with nested providers. The React DevTools "Profiler" tab and "Why did this render?" highlighting help here, but it's still a good reason to keep providers small and focused.

React 19: use(Context) as an alternative to useContext

In React 19 you can read a context with the use API. Despite its name, use is not a Hook. Unlike useContext, it can be called inside conditionals and loops, but it has the same context subscription behavior:

import { use } from 'react';

function Profile() {
  const user = use(UserContext);
  return <div>{user.name}</div>;
}

useContext still works and is not going away — use(Context) is just more flexible.

Further reading

• Passing data deeply with context
• use API reference
• React.memo
• Redux Toolkit
• Zustand
• Jotai
• use-context-selector

Exercises

TL;DR

Hooks let function components use state, context, refs, effects, and other React features without classes. Custom Hooks compose reusable stateful logic without adding wrapper components. React 19 added Hooks such as useActionState and useOptimistic, while React DOM provides useFormStatus. React 19's similarly named use(resource) is an API rather than a Hook and follows different call-order rules.

Benefits of using hooks in React

Hooks let function components compose stateful behavior while keeping related setup, updates, and cleanup together.

Why hooks were introduced

Before hooks (React 16.8, Feb 2019), the main ways to share stateful logic between components were higher-order components (HOCs) and render props. Repeated use of either pattern could produce deeply nested wrapper trees and obscure data flow in React DevTools. Class components also required this handling and often split one synchronization concern across componentDidMount, componentDidUpdate, and componentWillUnmount.

Hooks let components compose stateful logic through functions without adding wrapper components or relying on class lifecycle methods.

Reusable logic via custom hooks

Custom hooks let you extract a related combination of state, Effects, and other hooks into a function that components can call. Unlike an HOC, each custom Hook adds no wrapper component to the rendered tree.

import { useSyncExternalStore } from 'react';

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function getSnapshot() {
  return navigator.onLine;
}

function getServerSnapshot() {
  return true;
}

function useOnlineStatus() {
  return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);
}

function StatusBar() {
  const isOnline = useOnlineStatus();
  return <div>{isOnline ? 'Online' : 'Offline'}</div>;
}

This version uses useSyncExternalStore because online status is a browser value that changes outside React. The server snapshot also avoids reading navigator during server rendering and gives hydration a deterministic initial value.

Simplified state management

useState adds local state to any function component without converting it to a class:

import { useState } from 'react';

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

For more complex state transitions, useReducer gives you a Redux-style reducer locally to a component or feature.

Side effects without lifecycle methods

useEffect replaces componentDidMount, componentDidUpdate, and componentWillUnmount with a single API where setup and cleanup live next to each other instead of being scattered across three methods:

import { useEffect } from 'react';
import { createConnection } from './chat-api';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(roomId);
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]);

  return <h1>Room: {roomId}</h1>;
}

No more this

Function components and hooks have no this, so there's nothing to bind, no .bind(this) in constructors, and no surprises about what this refers to in a callback.

React 19 Hooks and APIs unlock new patterns

React 19 adds several Hooks and related APIs that solve problems custom Hooks alone could not:

• use(promise) — read a promise (or context) inside a component, integrating with Suspense for loading states.
• useActionState — manage a form action's state (pending, error, result) with a single hook.
• useFormStatus — read the pending state of the nearest parent <form> from a child, e.g. to disable a submit button.
• useOptimistic — show an optimistic UI update while a mutation is in flight, automatically reverting on failure.

React Compiler 1.0 can additionally reduce manual useMemo/useCallback work in compatible code when the optional build-time optimizer is enabled.

Further reading

• Built-in React hooks
• Reusing logic with custom hooks
• use API reference
• useActionState
• useOptimistic

Exercises

TL;DR

React hooks have a few essential rules to ensure they work correctly. Call hooks at the top level of a function component or custom hook — never inside loops, conditions, nested functions, or after an early return. The use API is the exception: it is not a Hook and may be called conditionally or in loops, but it must still run inside a component or Hook and cannot be wrapped in try/catch. Lean on eslint-plugin-react-hooks to enforce these rules.

What are the rules of React hooks?

The Rules of Hooks preserve a consistent call order so React can associate each Hook call with the correct component state across renders.

Always call hooks at the top level

Hooks must be called in the same order on every render. That means you cannot call them inside loops, conditions, nested functions, or after an early return. React identifies which useState/useEffect/etc. call corresponds to which piece of state purely by call order — break the order and React's internal bookkeeping desyncs.

import { useState } from 'react';

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

  if (!enabled) return null;

  return (
    <button onClick={() => setCount((value) => value + 1)}>{count}</button>
  );
}

// Incorrect — hook inside an `if`
function ConditionalCounter({ enabled }) {
  if (enabled) {
    const [count, setCount] = useState(0); // hook order changes between renders
    return <div>{count}</div>;
  }
  return null;
}

// Incorrect — hook after an early return
function SelectableList({ items }) {
  if (items.length === 0) return null;
  const [selected, setSelected] = useState(null); // skipped on the early-return path
  return <List items={items} selected={selected} onSelect={setSelected} />;
}

To fix the early-return case, move the hook above the conditional:

import { useState } from 'react';

function SelectableList({ items }) {
  const [selected, setSelected] = useState(null);
  if (items.length === 0) return null;
  return <List items={items} selected={selected} onSelect={setSelected} />;
}

Stable call order lets React match each Hook to the same internal slot on every render; conditionally skipping one shifts every later match:

The special case: use

Despite its name, React's use(resource) API is not a Hook. You may call it inside conditions and loops because it does not store state by call order:

import { use } from 'react';

function Comments({ shouldLoad, commentsPromise }) {
  if (shouldLoad) {
    const comments = use(commentsPromise);
    return <CommentList comments={comments} />;
  }
  return null;
}

use still must be called from a component or custom Hook. It also cannot be wrapped in try/catch; use an error boundary to handle a rejected promise.

Only call hooks from React functions

Hooks can only be called from:

1. React function components.
2. Other custom hooks (which by convention must have a name starting with use).

Calling a hook from a regular utility function, a class component, or an event handler is not allowed.

import { useState } from 'react';

// Correct — function component
function MyComponent() {
  const [count, setCount] = useState(0);
  return <div>{count}</div>;
}

// Correct — custom hook (name starts with `use`)
function useCounter(initial = 0) {
  const [count, setCount] = useState(initial);
  const increment = () => setCount((c) => c + 1);
  return { count, increment };
}

// Incorrect — plain function, not a component or hook
function regularFunction() {
  const [count, setCount] = useState(0); // violates the rules of hooks
}

The use prefix isn't cosmetic — it identifies a function as a custom Hook and lets the linter enforce call-order rules at its call sites. If a function that calls Hooks is instead named getCounter, the linter reports that Hooks are being called from a function that is neither a component nor a custom Hook.

Use eslint-plugin-react-hooks

The eslint-plugin-react-hooks package automates enforcement of these rules. Its two foundational rules are react-hooks/rules-of-hooks (call order and valid call sites) and react-hooks/exhaustive-deps (reactive dependencies for Effects and memoization Hooks). The recommended preset also enables additional Rules of React and React Compiler diagnostics.

npm install eslint-plugin-react-hooks --save-dev

For a legacy .eslintrc config:

{
  "extends": ["plugin:react-hooks/recommended"]
}

For ESLint's flat config (eslint.config.js), use the plugin's flat recommended preset:

import { defineConfig } from 'eslint/config';
import reactHooks from 'eslint-plugin-react-hooks';

export default defineConfig([reactHooks.configs.flat.recommended]);

The package also provides Compiler-powered lint rules. Keep it current when using newer APIs such as useEffectEvent so dependency suggestions follow their special semantics.

A note on the React Compiler

React Compiler 1.0 is a stable, optional build-time tool. When it is enabled, it can reduce the need for hand-written useMemo, useCallback, and memo. It does not change the rules above: ordinary Hooks must still be called unconditionally at the top level, and use retains its separate rules. The Compiler relies on code following the Rules of React and skips optimizations it cannot safely apply.

Further reading

• Rules of hooks
• Built-in React hooks
• eslint-plugin-react-hooks reference
• React Compiler

Exercises

TL;DR

Both hooks run side effects after render, but they differ in when they fire relative to paint:

• useEffect runs after React commits. For effects not caused by an interaction, React generally lets the browser paint first; interaction-driven effects may run before paint. Use it for synchronizing with external systems when the work does not need to block paint.
• useLayoutEffect runs synchronously during the commit phase, after DOM mutations but before the browser paints. It blocks paint, so use it only when you need to measure the DOM and write to it in the same frame to avoid a visual flicker.

Both accept a dependency array with the same semantics. In development Strict Mode, React performs an extra setup-and-cleanup cycle before the real setup. Neither effect runs during server rendering; useLayoutEffect is especially unsuitable there because the server has no layout to measure.

Code example:

import { useEffect, useLayoutEffect, useRef } from 'react';

function Example() {
  const ref = useRef(null);

  useEffect(() => {
    console.log('useEffect: runs after paint');
  }, []);

  useLayoutEffect(() => {
    console.log('useLayoutEffect: runs before paint');
    console.log('Element width:', ref.current.offsetWidth);
  }, []);

  return <div ref={ref}>Hello</div>;
}

What is useEffect?

useEffect schedules synchronization work after React commits changes to the DOM. If the effect was not caused by an interaction, React generally lets the browser paint first. For interaction-driven effects, React may run it before paint so the event system can observe the result. If timing relative to paint is essential, use the appropriate browser scheduling API or useLayoutEffect rather than relying on useEffect always running afterward.

• It is the right default for data fetching, subscriptions, event listeners, and logging.
• The dependency array controls when React re-synchronizes: [a, b] means after the initial commit and after commits where a or b changed by Object.is; [] means after mounting; omitting the array means after every commit.
• In development Strict Mode, React runs one extra setup-and-cleanup cycle before the real setup. This surfaces missing cleanup logic; it is not a production behavior.

Code example

This Effect synchronizes with an external system after the component commits:

import { useEffect } from 'react';

function Example() {
  useEffect(() => {
    console.log('Mounted');
    return () => console.log('Cleanup on unmount');
  }, []); // [] deps: cleanup runs on unmount (plus the Strict Mode stress test in development)

  return <div>Hello, World!</div>;
}

In production, cleanup for an Effect with [] dependencies runs when the component unmounts. In development Strict Mode, React also performs the extra setup-and-cleanup stress test described above. With non-empty dependencies such as [userId], cleanup runs before the next setup when userId changes and again on unmount.

Common use cases

Use useEffect for synchronization that does not need to block the browser's next paint:

• Fetching data from an API
• Setting up subscriptions (e.g., WebSocket connections)
• Logging or analytics tracking
• Adding and removing event listeners that do not affect layout

What is useLayoutEffect?

useLayoutEffect runs synchronously during the commit phase, after React has written to the DOM but before the browser paints. Because it blocks paint, anything you do inside it delays the first visible frame — but in return you can measure the just-committed DOM and make adjustments atomically, with no flicker.

• Use it when you need to read layout (e.g. getBoundingClientRect, offsetWidth) and then synchronously set state or style so the user never sees the "wrong" frame.
• Keep the body cheap — expensive work here stalls paint.
• Effects do not run during server rendering, and useLayoutEffect cannot contribute to server HTML because there is no layout to measure. Prefer useEffect when the first painted frame can be corrected later. If the content fundamentally depends on layout, render that content only after hydration. Libraries sometimes expose a useIsomorphicLayoutEffect alias that selects useEffect on the server and useLayoutEffect in the browser.

Code example

This layout Effect measures committed DOM and updates state before the browser paints the result:

import { useLayoutEffect, useRef, useState } from 'react';

function Tooltip({ children }) {
  const ref = useRef(null);
  const [height, setHeight] = useState(0);

  useLayoutEffect(() => {
    // Measure and commit the height before the user sees a frame
    setHeight(ref.current.getBoundingClientRect().height);
  }, []);

  return (
    <div ref={ref} style={{ marginTop: -height }}>
      {children}
    </div>
  );
}

Common use cases

Reserve useLayoutEffect for layout reads or writes that must complete in the same frame:

• Measuring a DOM node and writing back state/style in the same frame
• Positioning tooltips, popovers, or floating elements based on layout
• Fixing flicker caused by a measure-then-correct pattern

useInsertionEffect

useInsertionEffect runs before layout effects so CSS-in-JS libraries can inject <style> tags before layout is read. It may run before or after the DOM itself is updated, refs are not attached yet, and it cannot update state. Application code should almost never use it; reach for useEffect or useLayoutEffect first.

Dependency arrays and the exhaustive-deps lint rule

Both hooks take a dependency array with the same rules. React compares each entry to the previous render with Object.is and re-runs the effect (after running the previous cleanup) when any of them changed. The react-hooks/exhaustive-deps ESLint rule flags missing dependencies and is considered required in most React codebases — silencing it usually hides a stale-closure bug. If a value would make the effect re-run too often, the fix is usually to move it inside the effect, memoize it, or convert it to a ref, not to omit it.

Key differences between useEffect and useLayoutEffect

The APIs share the same dependency model but run at different points relative to browser paint.

Timing

The timing distinction determines whether an Effect can delay visible output:

• useEffect: Runs after commit and generally after paint for non-interaction effects, but may run before paint when caused by an interaction.
• useLayoutEffect: Fires synchronously during commit, before the browser paints.

The usual non-interaction timeline puts layout work directly in the commit path and ordinary Effect work after the browser has painted:

Blocking behavior

Layout Effects run synchronously in the commit path, while ordinary Effects generally allow paint first:

• useEffect: Generally does not block paint for non-interaction Effects. Interaction-triggered Effects can run before paint when React needs the result to be observable to the event system.
• useLayoutEffect: Blocks paint. The browser cannot repaint until the effect (and any resulting state update) has settled.

SSR behavior

Neither Effect runs during server rendering, but only the layout variant needs special care because its purpose depends on layout before paint:

• useEffect: Skipped on the server (client runs it after hydration).
• useLayoutEffect: Does not run on the server; use useEffect when possible or render layout-dependent content only after hydration so the server and initial client output still match.

Use case examples

Choose the least blocking API that still satisfies the synchronization requirement:

• useEffect: fetching data, subscriptions, logging, most event listeners.
• useLayoutEffect: measuring and adjusting the DOM in the same frame to prevent flicker.

Further reading

• React documentation: useEffect
• React documentation: useLayoutEffect
• React documentation: useInsertionEffect
• React documentation: You might not need an effect
• Differences between useEffect and useLayoutEffect

Exercises

TL;DR

The callback (or updater function) form of setState — both this.setState(prev => ...) in classes and setX(prev => ...) with useState — guarantees that each update is computed from the latest queued state rather than the value captured in your closure. Use it whenever the next state depends on the previous state, especially when you call the setter more than once in the same event handler or when the update may run after an await/timeout/promise.

import { useState } from 'react';

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

  function handleClick() {
    setCount((value) => value + 1);
    setCount((value) => value + 1);
  }
  return <button onClick={handleClick}>{count}</button>;
}

Purpose of the updater function form of setState

The updater form calculates next state from React's latest queued state rather than from the render snapshot captured by a closure.

What it is

React's state setters — this.setState in class components and the setX returned by useState in function components — accept either a new value or an updater function. The updater receives the latest queued state (and, for class components, the latest props) and returns the next state.

The community calls this the updater function form (sometimes "functional updater"). Recognizing that name is helpful in interviews.

Why it exists: state is a snapshot and updates are queued

State setters do not change the state snapshot in the currently running code. React queues the update for a subsequent render. Since React 18, automatic batching applies to React events and many other callbacks, including promise callbacks, timers, and native event handlers.

That means by the time the queued update actually runs, the variable you captured from the previous render may be stale.

The motivating bug — reading state directly between successive calls

The classic mistake is calling the setter more than once based on the current state value:

import { useState } from 'react';

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

  const handleClick = () => {
    // BUG: each call uses the same closed-over `count` (still 0 on this render).
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
    // After re-render, count is 1 — not 3.
  };

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

count is captured by the closure when the component rendered. All three calls compute 0 + 1, so React queues 1, 1, 1 and the final state is 1.

The same bug exists in classes — reading this.state.counter between setState calls returns the value from the last render, not the in-flight queued value.

The fix — pass an updater function

Passing a pure updater lets React apply each queued transformation in order:

import { useState } from 'react';

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

  const handleClick = () => {
    setCount((c) => c + 1);
    setCount((c) => c + 1);
    setCount((c) => c + 1);
    // Final count is 3 — each updater receives the result of the previous one.
  };

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

Each updater receives a snapshot of the latest queued state, not the value from your render closure.

When to use it

Use an updater whenever the next value is calculated from the previous value in the same state variable:

• The next state depends on the previous state (counters, toggles, append-to-array, increment-a-map-entry).
• You call the setter more than once in the same handler.
• The update happens after an await, setTimeout, promise resolution, or subscription callback — an intervening update may have made the closed-over value stale.
• Inside useEffect or useCallback when the state is read only to calculate its own next value — using the updater can remove that state value from the dependency list.

When you do not need it

If the new value does not depend on the previous state — setName('Alice'), setUser(response.data) — passing the value directly is fine and slightly more readable.

Class component equivalent

The same idea applies in class components, where the updater also receives props:

import { Component } from 'react';

class Counter extends Component {
  state = { counter: 0 };

  incrementCounter = () => {
    this.setState((prevState, props) => ({
      counter: prevState.counter + props.increment,
    }));
  };

  render() {
    return (
      <div>
        <p>Counter: {this.state.counter}</p>
        <button onClick={this.incrementCounter}>Increment</button>
      </div>
    );
  }
}

Further reading

• React Docs: Queueing a series of state updates
• React Docs: useState
• React Docs: State as a snapshot
• React 18: Automatic batching

Exercises

function handleClick() {
  setCount((value) => value + 2);
  setCount((value) => value * 3);
}

TL;DR

The dependency array of useEffect controls when React re-synchronizes the effect. With no array, React runs setup after every commit. With [], it runs setup after the component mounts (development Strict Mode immediately performs an extra setup/cleanup cycle). With dependencies, it runs after mount and again whenever any dependency changes according to Object.is. Cleanup runs before re-synchronization and after unmounting.

What does the dependency array of useEffect affect?

The dependency list controls when React re-synchronizes an Effect with the reactive values used by its setup function.

Introduction to useEffect

The useEffect hook in React is used to perform side effects in functional components. These side effects can include data fetching, subscriptions, or manually changing the DOM. The useEffect hook takes two arguments: a function that contains the side effect logic and an optional dependency array.

Dependency array

The dependency array is the second argument to the useEffect hook. It is an array of values that the effect depends on. React uses this array to determine when to re-run the effect.

useEffect(() => {
  // Side effect logic here
}, [dependency1, dependency2]);

How the dependency array affects useEffect

The three common dependency-list forms produce different setup and cleanup schedules:

1. Empty dependency array ([]):

   • The effect runs once after the initial render and its cleanup runs once on unmount.
   • This is roughly analogous to componentDidMount plus componentWillUnmount, but with an important caveat: at a Strict Mode root in development, React performs an extra Effect setup-and-cleanup cycle before the real setup. This stress-tests cleanup without representing a second production mount.
   useEffect(() => {
     // This code runs after the initial render
     return () => {
       // Cleanup runs on unmount
     };
   }, []);

2. Dependency array with variables:

   • The effect runs after the initial render and whenever any of the specified dependencies change.
   • React compares each dependency with its previous value using Object.is (reference equality, not a deep or shallow object comparison). Inline objects, arrays, or functions therefore change identity on every render unless memoized.
   useEffect(() => {
     // This code runs after the initial render and whenever dependency1 or dependency2 changes
   }, [dependency1, dependency2]);

3. No dependency array:

   • The effect runs after every render.
   • This can lead to performance issues if the effect is expensive.
   useEffect(() => {
     // This code runs after every render
   });

The dependency-list form selects the schedule, while a changed dependency also determines when cleanup must precede the next setup:

Cleanup behavior on dependency change

When dependencies change, React first runs the previous effect's cleanup function (if any) before running the effect again with the new values. The same is true on unmount. This means dependency changes effectively perform a tear-down/set-up cycle, which matters for subscriptions, intervals, and event listeners.

useEffect(() => {
  const subscription = source.subscribe(id);
  return () => subscription.unsubscribe(); // runs before next effect or on unmount
}, [id]);

The react-hooks/exhaustive-deps lint rule

The official eslint-plugin-react-hooks ships an exhaustive-deps rule that warns when reactive values used inside an effect are missing from the dependency array. Treat its warnings as bugs — silencing the rule is almost always the wrong fix and a common source of stale closures.

Common pitfalls

Incorrect dependencies either leave an Effect synchronized with stale values or cause unnecessary repeated setup:

1. Stale closures:

   • If you use state or props inside the effect without including them in the dependency array, you might end up with stale values.
   • Always include all state and props that the effect depends on in the dependency array.
   const [count, setCount] = useState(0);
   
   useEffect(() => {
     const handle = setInterval(() => {
       console.log(count); // This might log stale values if `count` is not in the dependency array
     }, 1000);
   
     return () => clearInterval(handle);
   }, [count]); // Ensure `count` is included in the dependency array

   React 19.2 introduced the stable useEffectEvent API for logic that is conceptually an event fired by an Effect. It can read the latest committed props and state without making the surrounding Effect re-synchronize:

   const onTick = useEffectEvent(() => {
     console.log(count); // always reads the latest count
   });
   
   useEffect(() => {
     const handle = setInterval(onTick, 1000);
     return () => clearInterval(handle);
   }, []); // effect does not need `count` in its deps

   Effect Events are not a general way to suppress dependencies: declare them in the same component or custom Hook as their Effect, call them only from Effects or other Effect Events, and do not include them in dependency arrays. eslint-plugin-react-hooks v6.1.1 or newer enforces these restrictions.

2. Functions as dependencies:

   • Functions are recreated on every render, so including them in the dependency array can cause the effect to run more often than necessary.
   • Use useCallback to memoize functions if they need to be included in the dependency array.
   const handleClick = useCallback(() => {
     console.log('clicked');
   }, []);
   
   useEffect(() => {
     window.addEventListener('click', handleClick);
     return () => window.removeEventListener('click', handleClick);
   }, [handleClick]); // stable identity, so this effect does not re-subscribe each render

Further reading

• React Docs: Using the Effect Hook
• React Docs: Rules of Hooks
• React Docs: useEffectEvent
• Overreacted: A Complete Guide to useEffect

Exercises

TL;DR

The useRef hook in React is used to create a mutable object that persists across renders. It can be used to access and manipulate DOM elements directly, store mutable values that do not cause re-renders when updated, and keep a reference to a value without triggering a re-render. For example, you can use useRef to focus an input element:

import { useEffect, useRef } from 'react';

function TextInputWithFocusButton() {
  const inputEl = useRef(null);

  useEffect(() => {
    inputEl.current?.focus();
  }, []);

  return <input ref={inputEl} type="text" />;
}