Why Can Changing Parent State Cause a Child to Re-render?

One of the most common questions when learning React rendering is:

Why can changing a Parent's state cause a Child component to re-render, even when the Child's props haven't changed?

To answer this properly, we first need to understand how React's rendering mechanism works, especially the difference between the Render Phase and the Commit Phase.

React Elements and the Element Tree

Everything we describe in React's UI is represented using React Elements.

For example:

function Parent() {
  return <Child />
}

Conceptually, React can represent this UI as a tree:

With a larger application, the structure might look like:

A React Element is a declarative description of the UI. It contains information such as the element's type, props, and children.

But React needs more than this description to efficiently process updates.

This is where Fiber comes in.

What Is the Fiber Tree?

React uses an internal data structure called Fiber to represent and process rendering work.

The Fiber tree corresponds closely to the component hierarchy:

However, the Fiber tree and React Element tree are not the same thing.

A useful mental model is:

React Element: What should the UI look like?

Fiber: How does React track and process the work required to produce and update that UI?

So Fiber should not be thought of simply as a tree that "describes changes and priority."

It is better described as:

React's internal data structure and unit of work for tracking and processing rendering work.

Render Phase vs Commit Phase

Now we can look at what happens when something changes.

Suppose a component updates its state:

setCount(count + 1)

React needs to determine what the UI should look like after this update.

This work is divided conceptually into two important phases:

These phases have very different responsibilities.

The Render Phase

The Render Phase is where React calculates what the UI should look like after an update.

During this phase, React may execute component functions.

For example:

function Child() {
  console.log('Child rendered')
  return <div>Hello</div>
}

If "Child rendered" appears in the console, the component function executed.

But this does not necessarily mean that React changed the DOM.

The Commit Phase

After React finishes the necessary rendering work, it enters the Commit Phase.

The Commit Phase is where React applies the required changes to the host environment, such as the browser DOM.

For example, if React determines that a DOM element's text needs to change, the actual DOM mutation happens during the Commit Phase.

Therefore a component can re-render without causing any visible DOM change:

Component function executes ≠ DOM changes

What Is Reconciliation?

During the Render Phase, React needs to determine how the new rendering result relates to the existing UI.

This process is commonly called reconciliation.

For example, imagine the previous UI versus the new result:

React needs to determine:

• Can existing components be reused?
• Was a component added?
• Was a component removed?
• Did the element type change?
• Did a list item's key change?
• Does a subtree need to be processed?
• Can React bail out of some work?

Reconciliation is therefore about determining how React should transition from the existing UI representation to the new one.

It is important not to think of reconciliation as a completely separate tool that simply compares two full Element Trees.

Reconciliation happens as part of React's rendering work while React processes the Fiber tree and determines what work is necessary.

Re-render Propagation

Now we can introduce re-render propagation.

Consider this example:

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

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

function Child() {
  console.log('Child rendered')
  return <p>Hello</p>
}

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

This is what we mean by re-render propagation.

An update in a component can cause React to process descendants in that component's subtree during the Render Phase.

However, propagation does not mean that every descendant must always execute.

React can stop processing parts of the tree when it determines that the work is unnecessary.

This is called a bailout.

For example:

const Child = React.memo(function Child() {
  return <div>Hello</div>
})

If the Child's props are unchanged, React.memo can allow React to bail out of rendering that component.

const Child = React.memo(function Child() {
  console.log('Child rendered')
  return <p>Hello</p>
})

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

Try it yourself. Click the button, watch the console, then switch on React.memo and click again:

Therefore, the more accurate statement is:

A state update in a Parent can propagate rendering work through its subtree, causing descendants to potentially re-render. React can use bailout mechanisms to avoid unnecessary work.

This is why we should not say:

"When the Parent re-renders, every Child definitely re-renders."

Instead, say:

"When the Parent updates, React processes the Parent's subtree, and Child components may re-render unless React can bail out of that work."

Now We Can Answer the Original Question

We can now put everything together.

When the Parent's state changes, the flow is approximately:

The important part is:

The Child does not need to have changed its own props for its component function to potentially execute again.

The update originated in the Parent, and React needs to process the relevant subtree during the Render Phase.

However, whether the Child actually executes depends on React's ability to bail out of that work and on other factors such as memoization, context, state, and element identity.

The Important Distinction: Render vs DOM Update

This leads to one of the most important concepts in React performance.

Consider:

function Child() {
  console.log('Child rendered')
  return <div>Hello</div>
}

If the Parent updates and the console prints Child rendered, we know that the Child function executed.

But that does not mean React performed a DOM update. React may calculate that the resulting DOM is identical.

This distinction prevents a common misunderstanding when discussing "unnecessary re-renders."

The Complete Mental Model

We can now summarize the complete process:

And each concept has a different responsibility:

Check your understanding