React Interview Questions

TL;DR

React is a JavaScript library created by Facebook for building user interfaces, primarily for single-page applications. It allows developers to create reusable components that manage their own state. Key benefits of React include a component-based architecture for modular code, the virtual DOM for efficient updates, a declarative UI for more readable code, one-way data binding for predictable data flow, and a strong community and ecosystem with abundant resources and tools.

Key characteristics of React:

• Declarative: You describe the desired state of your UI based on data, and React handles updating the actual DOM efficiently.
• Component-based: Build reusable and modular UI elements (components) that manage their own state and logic.
• Virtual DOM: React uses a lightweight in-memory representation of the actual DOM, allowing it to perform updates selectively and efficiently.
• JSX: While not mandatory, JSX provides a syntax extension that allows you to write HTML-like structures within your JavaScript code, making UI development more intuitive.

What is React?

React is an open-source JavaScript library developed by Meta (formerly Facebook) for building user interfaces. It focuses on the view layer of an application and is especially useful for creating single-page applications where a seamless user experience is crucial. React allows developers to build encapsulated components that manage their own state and compose them to create complex UIs.

Modern React is hooks-first and function-component-driven. JSX, an HTML-like syntax extension to JavaScript, is the standard way to describe UI. With React 19 (released December 2024), React also officially supports React Server Components, the use() hook for unwrapping promises and context, Actions for form/data mutations, and the React Compiler (RC), which automatically memoizes components so you rarely need to reach for useMemo/useCallback by hand.

Benefits of React

1. Component-based architecture

React encourages breaking down your UI into independent, reusable components. Each component encapsulates its own state, logic, and rendering, making your code:

• Modular and reusable: Components can be easily reused across different parts of your application or even in other projects.
• Maintainable: Changes within a component are isolated, reducing the risk of unintended side effects.
• Easier to test: Components can be tested independently, ensuring their functionality and reliability.

2. Virtual DOM and efficient updates

React utilizes a virtual DOM, a lightweight in-memory representation of the actual DOM. When data changes, React first updates the virtual DOM, then compares it to the previous version. This process, known as diffing, allows React to identify the minimal set of changes required in the actual DOM. By updating only the necessary elements, React minimizes expensive DOM manipulations, resulting in significant performance improvements.

3. Large and active community

React boasts a vast and active community of developers worldwide. This translates to:

• Extensive documentation and resources: Find comprehensive documentation, tutorials, and community-driven resources to aid your learning and development process.
• Abundant third-party libraries and tools: Leverage a rich ecosystem of pre-built components, libraries, and tools that extend React's functionality and streamline development.
• Strong community support: Seek help, share knowledge, and engage with fellow developers through forums, online communities, and meetups.

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 communicate back up through callbacks rather than mutating shared state directly. This makes the flow of data explicit and easy to trace, which leads to more predictable behavior and simpler debugging compared to two-way binding approaches.

5. Hooks and function components

Modern React is built around function components and hooks. Hooks like useState, useEffect, useReducer, useContext, and useRef let you manage state, side effects, and shared logic without classes. Custom hooks make it easy to extract and reuse stateful logic across components.

6. Learn once, write anywhere

React's versatility extends beyond web development. With React Native, you can apply your React knowledge to build native mobile applications for iOS and Android, sharing components and logic across web and mobile and targeting multiple platforms without learning entirely new technologies.

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/

TL;DR

A React Node is anything React can render: a React Element, a string, a number, an array of nodes, a fragment, a portal, null, undefined, false, or true. A React Element is the immutable plain object React produces from JSX or React.createElement describing what to render. A React Component is a function (or, historically, a class) that accepts props and returns React Nodes. Elements describe the UI; components are the factories that produce those elements.

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 and numbers (rendered as text)
• Arrays of React Nodes (commonly produced by .map(...))
• Fragments (<>...</> or <React.Fragment>)
• Portals (created with createPortal)
• 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!',
);

Internally each element carries a $$typeof symbol (Symbol.for('react.element') / 'react.transitional.element' in newer versions) that React and serializers use to recognise a real element and prevent injection attacks from JSON. Elements are cheap to create and are throwaway descriptions — React diffs them against the previous tree and updates the actual DOM.

React component

A React Component accepts inputs (props) and returns React Nodes that describe the UI. 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 still work but are legacy in React 19 — there are no new class-only features, the legacy lifecycles (componentWillMount, componentWillReceiveProps, componentWillUpdate) and string refs are gone, and new APIs (Hooks, Server Components, the React Compiler) target functions only. Prefer functions for new code.

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

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

TL;DR

JSX stands for JavaScript XML. It is a syntax extension for JavaScript that allows you to write HTML-like code within JavaScript. JSX makes it easier to create React components by allowing you to write what looks like HTML directly in your JavaScript code. Under the hood, JSX is transformed into JavaScript function calls, typically using a tool like Babel. For example, <div>Hello, world!</div> in JSX is transformed into React.createElement('div', null, 'Hello, world!').

What is JSX and how does it work?

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.

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.
• URL-valued attributes such as href and src are not sanitized by React — href="javascript:..." will execute if the URL string comes from an attacker-controlled source. Validate URLs yourself.

Further reading

• React: Writing markup with JSX
• React: Introducing the new JSX transform
• Babel

TL;DR

State is data a component owns and can update over time; props are data a component receives from its parent and is not allowed to mutate. State changes trigger a re-render of the owning component (and its descendants); prop changes happen because the parent re-rendered with new values. 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

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 are asynchronous and batched — React groups updates triggered in the same event (and, since React 18, also in promises, timeouts, and native event handlers) and re-renders once.
• 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);

  // Wrong: reads a possibly stale `count` if multiple updates batch together
  // 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>
  );
}

Class components use this.setState, but writing this.setState({ count: this.state.count + 1 }) is the exact stale-read anti-pattern the React docs warn against — pass a function (this.setState(prev => ({ count: prev.count + 1 }))) for the same reason. New code should use useState in a function component.

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

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)

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?

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

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

• 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

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.

// Bad: array index as key in a list that can change order.
<ul>
  {items.map((item, index) => (
    <ListItem key={index} value={item.value} />
  ))}
</ul>

// Good: stable unique identifier from your data.
<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
• Why keys are important in React
• Preserving and Resetting State in React

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

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 box on the second row and then deletes the first row, the second item's data shifts up to index 0, but React keeps the original <li key={0}> mounted with its checked checkbox and previously typed text. The visible label changes; the DOM state does not. Switching to key={todo.id} fixes it because React then unmounts the deleted row and keeps the surviving row's DOM intact.

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
• Why using array index as a key is an anti-pattern
• React performance optimization with keys

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?

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. Pairing value with no onChange (or vice versa) makes the input read-only or warns in development; pick one mode per field.

<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(prevState, formData) {
  const name = formData.get('name');
  // ...persist...
  return { ok: true, name };
}

function NameForm() {
  const [state, formAction] = useActionState(saveName, null);
  return (
    <form action={formAction}>
      <input name="name" defaultValue={state?.name ?? ''} />
      <SubmitButton />
    </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

State management

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

Data flow

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

When to use which

• 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

TL;DR

Context in React is convenient but easy to misuse. The biggest pitfalls are passing a fresh object/array as the provider value on every render (which forces every consumer to re-render), assuming React.memo will stop context-driven re-renders (it won't), and reaching for context as a general-purpose state manager. For frequently-changing or independent slices of state, split context into multiple providers, memoize the value, or use a dedicated state library like Redux, Zustand, or Jotai.

Pitfalls of using context in React

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 (or letting the React Compiler do it for you):

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 is a transport mechanism for passing values down the tree, not a state manager. It has no caching, no devtools, no middleware, no fine-grained updates. For complex client state, prefer Redux Toolkit, Zustand, or Jotai. For server state (data from APIs), use TanStack Query, SWR, or RTK Query — don't store fetched data in context.

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) instead of useContext

In React 19 you can read a context with the new use API. Unlike useContext, use can be called inside conditionals and loops:

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

TL;DR

Hooks let you use state and other React features in plain functions, without classes. They were introduced to solve real pain points in the class-component era — "wrapper hell" from HOCs and render props, the awkwardness of this binding, and the difficulty of sharing stateful logic between components. Custom hooks make that logic genuinely reusable through composition. React 19 expands the set further with hooks like use, useActionState, useOptimistic, and useFormStatus for promises, forms, and optimistic UI.

Benefits of using hooks in React

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. Both produced deeply nested component trees — the so-called "wrapper hell" you'd see in React DevTools — and made it hard to follow data flow. Class components also forced you to bind this for handlers, split related logic across componentDidMount/componentDidUpdate/componentWillUnmount, and made it nearly impossible to extract a piece of stateful behaviour without restructuring the component tree.

Hooks solve all of these by moving stateful logic into plain functions you can compose, with no this, no extra wrappers, and no lifecycle-method scatter.

Reusable logic via custom hooks

Custom hooks let you extract any combination of state, effects, and other hooks into a function that any component can call. This is composition rather than inheritance, and it scales much better than HOCs — you can use as many custom hooks in a component as you want without nesting.

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(navigator.onLine);
  useEffect(() => {
    const on = () => setIsOnline(true);
    const off = () => setIsOnline(false);
    window.addEventListener('online', on);
    window.addEventListener('offline', off);
    return () => {
      window.removeEventListener('online', on);
      window.removeEventListener('offline', off);
    };
  }, []);
  return isOnline;
}

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

Because custom hooks are just function calls, you also break complex components into smaller, named pieces of logic — making them easier to read.

Simplified state management

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

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

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:

useEffect(() => {
  // setup (mount + when dependencies change)
  return () => {
    // cleanup (unmount + before next run)
  };
}, [dependencies]);

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 unlock new patterns

React 19 adds several hooks 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.

Combined with the React Compiler (RC/stable by 2026), these reduce a lot of the manual useMemo/useCallback and form-state boilerplate that earlier hook-based code needed.

Further reading

• Built-in React hooks
• Reusing logic with custom hooks
• Introducing hooks (the original motivation)
• use API reference
• useActionState
• useOptimistic

TL;DR

React hooks have a few essential rules to ensure they work correctly. Always call hooks at the top level of your component or custom hook — never inside loops, conditions, nested functions, or after an early return. Only call hooks from React function components or other custom hooks (whose names must start with use). Lean on eslint-plugin-react-hooks to enforce these rules. The React Compiler (RC/stable by 2026) relaxes the need for some manual memoization, but the rules of hooks themselves still apply.

What are the rules of React hooks?

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.

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

  if (!enabled) {
    // Use the value conditionally — fine.
  }

  return <div>{count}</div>;
}

// Incorrect — hook inside an `if`
function MyComponent({ 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 MyComponent({ 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:

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

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.

// 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's how the linter identifies a custom hook and enforces the rules of hooks inside it. Naming a function getCounter instead of useCounter will silently disable those checks.

Use eslint-plugin-react-hooks

The eslint-plugin-react-hooks package automates enforcement of these rules. It ships two main rules: react-hooks/rules-of-hooks (call order, where hooks may be called) and react-hooks/exhaustive-deps (correct dependency arrays for useEffect, useMemo, useCallback).

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

For an ESLint legacy .eslintrc config:

{
  "plugins": ["react-hooks"],
  "rules": {
    "react-hooks/rules-of-hooks": "error",
    "react-hooks/exhaustive-deps": "warn"
  }
}

For ESLint 9's flat config (eslint.config.js), import the plugin and spread its recommended config:

import reactHooks from 'eslint-plugin-react-hooks';

export default [
  {
    plugins: { 'react-hooks': reactHooks },
    rules: reactHooks.configs.recommended.rules,
  },
];

eslint-plugin-react-hooks v5 added flat-config support and ships an additional rule set for the React Compiler when you enable it.

A note on the React Compiler

The React Compiler (RC and on track for stable in 2026) auto-memoizes components and values, removing most of the need for hand-written useMemo and useCallback. It does not change the rules of hooks — your hooks still have to be called unconditionally at the top level, from components or custom hooks. The compiler actually relies on those rules to do its job safely, and will refuse to optimize components that violate them.

Further reading

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

TL;DR

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

• useEffect runs asynchronously after the browser has painted. It does not block the user from seeing the new frame. Use it for data fetching, subscriptions, logging, and most side effects.
• 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, both fire twice on mount in Strict Mode development builds, and useLayoutEffect has no effect during server rendering (React warns if you use it in SSR).

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 a side effect to run after React commits changes to the DOM and the browser has painted. It is non-blocking — the user sees the new frame first, then the effect runs.

• It is the right default for data fetching, subscriptions, event listeners, and logging.
• The dependency array controls when it re-fires: [a, b] means "after any render where a or b changed (by Object.is)"; [] means "only after mount"; omitting the array means "after every render."
• In Strict Mode during development, React mounts, unmounts, and remounts each component once, so effects (and their cleanup) fire twice. This surfaces missing cleanup logic. Production runs each effect once.

Code example

import { useEffect } from 'react';

function Example() {
  useEffect(() => {
    console.log('Mounted');
    return () => console.log('Cleanup on unmount');
  }, []); // [] deps: cleanup runs only on unmount

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

With [] deps, the cleanup runs only when the component unmounts. With non-empty deps like [userId], the cleanup runs before the next effect fires (when userId changes) and again on unmount.

Common use cases

• 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.
• During server rendering it does nothing (there is no layout to measure) and React logs a warning if you schedule one. Either gate it behind a client check or reach for useEffect instead. For libraries that need to pick one based on environment, useInsertionEffect (see below) or a useIsomorphicLayoutEffect pattern is common.

Code example

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

• 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 fires even earlier than useLayoutEffect — before React makes any DOM mutations. It exists for CSS-in-JS libraries that need to inject <style> tags before layout effects read them. 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

Timing

• useEffect: Fires asynchronously after the browser paints.
• useLayoutEffect: Fires synchronously during commit, before the browser paints.

Blocking behavior

• useEffect: Non-blocking. Users see the new frame immediately.
• useLayoutEffect: Blocks paint. The browser cannot repaint until the effect (and any resulting state update) has settled.

SSR behavior

• useEffect: Skipped on the server (client runs it after hydration).
• useLayoutEffect: No-ops on the server and warns; avoid it in isomorphic code or gate it on typeof window !== 'undefined'.

Use case examples

• 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

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.

// Modern hooks form (preferred)
const [count, setCount] = useState(0);

const handleClick = () => {
  setCount((c) => c + 1);
  setCount((c) => c + 1); // Both run; final count is +2.
};

// Legacy class form
this.setState((prevState, props) => ({
  counter: prevState.counter + props.increment,
}));

Purpose of the updater function form of setState

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"). Recognising that name is helpful in interviews.

Why it exists: state updates are batched and asynchronous

State setters do not change state immediately. React queues the update and applies it later, then re-renders. Since React 18, this batching is automatic and applies everywhere — event handlers, promises, setTimeout, native event handlers — not only inside React event handlers as in earlier versions.

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:

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

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

• 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 — by then the closed-over value is almost certainly stale.
• Inside useEffect or useCallback where omitting the state from deps would otherwise cause stale-closure bugs — using the updater lets you drop the value from the dependency array.

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:

class Counter extends React.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

TL;DR

The dependency array of useEffect determines when the effect should re-run. If the array is empty, the effect runs only once after the initial render. If it contains variables, the effect runs whenever any of those variables change. If omitted, the effect runs after every render.

What does the dependency array of useEffect affect?

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

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: in development with Strict Mode, React intentionally mounts, unmounts, and remounts each component to surface bugs in effect cleanup. Your effect (and its cleanup) will run twice on the initial mount in development. Production runs the effect once.
   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
   });

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

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

   In React 19, useEffectEvent (now stable) provides a way to read the latest value of a prop or state from inside an effect without making the effect re-subscribe on every change. It is the recommended escape hatch for the "I want the latest value, but I do not want this effect to re-run" pattern:

   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

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

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 React, { useRef, useEffect } from 'react';

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

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

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

What is the useRef hook in React and when should it be used?

Introduction to useRef

The useRef hook in React is a function that returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component. Updating ref.current does not trigger a re-render.

A few important rules:

• Do not read or write ref.current during rendering. React only guarantees the ref's value is settled after commit; mutating it during render makes components impure and is disallowed.
• It is fine (and expected) to read or write ref.current inside event handlers, effects, or callbacks.

Key use cases for useRef

Accessing and manipulating DOM elements

One of the primary use cases for useRef is to directly access and manipulate DOM elements. This is particularly useful when you need to interact with the DOM in ways that are not easily achievable through React's declarative approach.

Example:

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

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

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

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

In this example, the useRef hook is used to create a reference to the input element, and the useEffect hook is used to focus the input element when the component mounts. The optional chaining (?.) guards against the rare case where the element is not yet attached, which is a good habit under React 19's stricter dev-mode checks.

Storing mutable values across renders

useRef can also be used to store any mutable value that should persist across renders without causing one. Common examples are interval/timeout IDs, the previous value of a prop or state, an instance of a non-React object (e.g. a chart or map controller), or a counter used inside event handlers.

import React, { useRef, useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);
  const prevCountRef = useRef(undefined);

  useEffect(() => {
    prevCountRef.current = count;
  }, [count]);

  return (
    <div>
      <h1>Now: {count}</h1>
      <h2>Before: {prevCountRef.current}</h2>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

Here prevCountRef holds the previous value of count across renders, but updating it does not itself cause a re-render.

Refs in React 19

React 19 changed how refs interoperate with components in two important ways:

ref is now a regular prop — forwardRef is deprecated

In function components, ref is now an ordinary prop. You can accept it directly in your props and pass it to a DOM node (or to another component) without wrapping the component in React.forwardRef. forwardRef still works but is deprecated and scheduled for removal in a future major.

// React 19+: just accept `ref` as a prop.
function FancyInput({ ref, ...props }) {
  return <input ref={ref} {...props} />;
}

// Usage is unchanged at the call site:
function Parent() {
  const inputRef = useRef(null);
  return <FancyInput ref={inputRef} placeholder="Type..." />;
}

Cleanup functions from ref callbacks

Ref callbacks may now return a cleanup function, which React runs when the ref detaches (similar to useEffect). This removes the need for the older "called with null" pattern.

<input
  ref={(node) => {
    node.focus();
    return () => {
      // runs when the element unmounts or the ref changes
    };
  }}
/>

Further reading

• React documentation on useRef
• Using the useRef hook
• React 19 release notes

TL;DR

useCallback returns a memoized function whose identity only changes when one of its dependencies changes. The point is referential stability — so a React.memo-wrapped child does not re-render, or a useEffect whose deps include the function does not re-fire. Re-creating a plain function literal each render is essentially free; the actual cost being avoided is the downstream work triggered by a new reference.

const memoizedCallback = useCallback(() => {
  doSomething(a, b);
}, [a, b]);

Note for 2026: with the React Compiler (stable in React 19), most components no longer need manual useCallback / useMemo / React.memo — the compiler memoizes automatically. New code targeting a compiler-enabled project should generally not reach for useCallback unless profiling shows a specific need.

What is the useCallback hook in React and when should it be used?

What is useCallback?

The useCallback hook is a React hook that returns a memoized version of the callback function that only changes if one of the dependencies has changed. It is useful for optimizing performance by preventing unnecessary re-creations of functions.

Syntax

const memoizedCallback = useCallback(() => {
  doSomething(a, b);
}, [a, b]);

When should useCallback be used?

Preventing unnecessary re-renders of memoized children

When you pass a function as a prop to a React.memo-wrapped child, a new function reference on each parent render breaks the memoization and the child re-renders anyway. useCallback keeps the reference stable so React.memo can do its job.

A common bug is depending on a state value you also update inside the callback — the dependency changes after every click, so the memoization is useless:

// BAD: `count` is in the deps, so `handleClick` gets a new identity every click,
// defeating React.memo on the child.
const handleClick = useCallback(() => {
  setCount(count + 1);
}, [count]);

The fix is to use the functional updater form of setState, which lets you drop the value from the deps:

const ParentComponent = () => {
  const [count, setCount] = useState(0);

  // GOOD: empty deps, stable identity for the lifetime of the component.
  const handleClick = useCallback(() => {
    setCount((c) => c + 1);
  }, []);

  return <ChildComponent onClick={handleClick} />;
};

const ChildComponent = React.memo(({ onClick }) => {
  console.log('ChildComponent rendered');
  return <button onClick={onClick}>Click me</button>;
});

Stabilising functions used in useEffect deps

If a function is referenced inside an effect's dependency array, a fresh reference each render will cause the effect to re-run every render. Wrapping the function in useCallback (or moving it inside the effect) prevents that:

const fetchData = useCallback(async () => {
  const res = await fetch(`/api/items?query=${query}`);
  setItems(await res.json());
}, [query]);

useEffect(() => {
  fetchData();
}, [fetchData]);

Relationship to useMemo

useCallback(fn, deps) is exactly equivalent to useMemo(() => fn, deps) — it memoizes a value that happens to be a function. Use useCallback for readability when the value is a function.

Caveats

• It is not free: useCallback itself adds bookkeeping. For a function that is not passed to a memoized child or used in a dependency array, wrapping it usually makes the code slower, not faster.
• The cost being avoided is downstream re-renders, not the function literal itself. Allocating an arrow function on each render is essentially free.
• Dependencies must be correct: missing dependencies cause stale closures; over-specified ones defeat the memoization.
• The React Compiler removes most need for it: in a compiler-enabled codebase, prefer plain inline functions and let the compiler memoize.

Further reading

• React documentation on useCallback
• React memoization techniques
• Understanding React's useCallback and useMemo