Practice Questions

How does React decide when to re-render a component, and what role does render() play in that process?

HighIntermediateReact

By FrontendAtlas Team · Updated Jan 30, 2026

Preparing for interviews?

Use guided tracks for structured prep, then practice company-specific question sets when you want targeted interview coverage.

Explore interview tracks Browse company questions Open React prep path

Quick Answer

Explain what triggers a React component to re-render, what a “render” actually means (vs updating the DOM), and what role the class render() method (or function component body) plays in the render + commit pipeline.

Answer

Core idea

React re-renders a component when it thinks that component’s inputs might have changed (state/props/context). A re-render means: “run the component again to produce a new element tree.” It does not necessarily mean the browser DOM will change.

Trigger	What changed?	What React does	Notes / common gotcha
State update	`setState` / `setX` / `dispatch`	Schedules a render for that component	`useState` bails out if the new state is `Object.is`-equal to the old state; new object/array references always count as “changed”.
New props	Parent renders and passes props down	Child is rendered by default	Even if props are “equal by value”, React still re-renders unless the child is memoized (`React.memo`/`PureComponent`).
Context update	A `Context.Provider` value changes	All consuming components re-render	Context is identity-based: `{...}` created inline will change every render unless memoized.
Force update	`forceUpdate()` (class) or “dummy state”	Forces a render	Usually a code smell; prefer state/props-driven rendering.

The main reasons React decides to re-render a component

What happens during a re-render

React runs the component (function body or class render()) to build a new React element tree. Then it reconciles (diffs) it against the previous tree. Only the differences are committed to the DOM.

Phase	What runs here	What must be true
Render phase	Component function body / class `render()`	Must be pure: no side effects (no data fetching, subscriptions, DOM writes).
Commit phase	DOM mutations + layout effects	Safe place for effects: `useEffect`, `useLayoutEffect`, lifecycle methods.

Render vs commit (why render() must be pure)

JSX

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

  // This function body is the “render” for function components.
  // It runs again when state/props/context changes.
  return (
    <button onClick={() => setCount((c) => c + 1)}>
      Count: {count}
    </button>
  );
}

So what is render() doing?

render() does not “trigger” updates. It’s the function React calls after an update is scheduled, to compute the next UI description. For function components, the component function itself plays the same role as render().

JSX

class Profile extends React.Component {
  render() {
    // Called during the render phase to compute UI.
    return <h1>{this.props.name}</h1>;
  }
}

Skipping re-renders (bailouts)

By default, parent re-renders propagate to children. To skip work, React needs an explicit bailout rule.

Technique	How it skips work	When to use
`React.memo(Component)`	Shallow-compares props; if equal, skips re-render	Pure presentational children with stable props
`PureComponent` / `shouldComponentUpdate`	Controls whether class component re-renders	Legacy/class codebases
Stable references	Avoid changing prop identity unnecessarily	Use `useCallback`/`useMemo` only when it prevents real re-renders

Common ways to prevent unnecessary re-renders

Summary

React re-renders when state/props/context might have changed. A “render” means recomputing the next React element tree, not necessarily updating the DOM. The class render() method (or function component body) is the pure computation React runs during the render phase; DOM updates happen later in the commit phase.