Interview answer drill

Use this React interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow 30-day foundations study plan Practice more React interview questions

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

HighIntermediateReact

By FrontendAtlas Team · Updated Apr 10, 2026

Interview focus

This React interview question tests whether you can explain React rerender vs DOM update: render, commit, bailouts, and remounts, connect it to production trade-offs, and handle common follow-up questions.

React rerender vs DOM update: render, commit, bailouts, and remounts explanation without falling back to memorized docs wording
Rendering and State reasoning, edge cases, and production failure modes
How you would answer the most likely React interview follow-up

Practice more React interview questions

Interview quick answer

Explain React rerenders through render vs commit, parent-child propagation, memo bailouts, context churn, and the follow-up confusion around remounts versus ordinary rerenders.

Full interview 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>;
  }
}

Worked example: parent re-renders, child logs, DOM barely changes

Imagine a search page where typing updates local input state in the parent. React may re-run the child result pane too, especially if you pass inline callbacks or config objects. That still does not prove the browser rewrote the whole subtree. It only proves React re-computed the next UI and then decided what, if anything, must be committed.

JSX

const SearchResults = React.memo(function SearchResults({ items, onSelect }) {
  console.log('SearchResults render');
  return items.map((item) => (
    <button key={item.id} onClick={() => onSelect(item.id)}>{item.label}</button>
  ));
});

function SearchPage({ allItems }) {
  const [query, setQuery] = React.useState('');
  const visible = allItems.filter((item) => item.label.includes(query));

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <SearchResults
        items={visible}
        onSelect={(id) => console.log('select', id)}
      />
    </>
  );
}

In that example, the inline onSelect function creates a new reference on every parent render, so React.memo cannot bail out even if the visible list did not change. The browser may only update the text input, but React still had to re-run SearchResults first.

Another production bug: context churn

Parent state is not the only rerender trigger. A provider value created inline can re-run every consumer even when the field they care about did not change.

JSX

const SearchContext = React.createContext(null);

function SearchShell() {
  const [theme, setTheme] = React.useState('dark');
  const [query, setQuery] = React.useState('');

  // ❌ New object identity every render
  const value = { query, setQuery };

  return (
    <SearchContext.Provider value={value}>
      <button onClick={() => setTheme((t) => t === 'dark' ? 'light' : 'dark')}>
        Toggle theme
      </button>
      <SearchBox />
    </SearchContext.Provider>
  );
}

// Even theme-only renders recreate value, so consumers can rerender too.

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

Event	What React means by it	What happens to local state
Initial mount	Component appears in the tree for the first time	Fresh state is created.
Re-render	React re-runs the component because inputs might have changed	Existing local state is preserved.
Remount	React treats it as a different component because key/type/position changed	Local state resets.
No-op commit	React rendered, diffed, and found nothing DOM-visible to change	State stays the same; the browser may not visibly update.

The follow-up distinction interviewers often want next

One-line distinction

Rerender means React ran the component again, remount means React threw away the old identity and local state, and commit means React actually mutated the DOM. Those are related, but they are not the same event.

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.