reactjs / reactjs/react.dev

[Typo]: Two docs give conflict answers about when effects will run

Open
#7,801 2 comments 0 reactions 1 assignee View on GitHub

@poteto is already working on this.

Since May 16, 2025.

type: typos
Dominant language
JavaScript
Stars
11.8k
Forks
7.9k
Avg merge
1d 11h
Merged PRs (30d)
11

Description

Summary

https://react.dev/learn/synchronizing-with-effects#how-to-write-an-effect
This link says React effects run after the commit phase, but

https://react.dev/reference/rules/components-and-hooks-must-be-pure#how-does-react-run-your-code
this link says it's after the rendering phase

Page

https://react.dev/learn/synchronizing-with-effects#how-to-write-an-effect

Details

In https://react.dev/learn/synchronizing-with-effects#how-to-write-an-effect, it says:

Declare an Effect. By default, your Effect will run after every commit.

(it also says:

Specify the Effect dependencies. Most Effects should only re-run when needed rather than after every render.)

But in https://react.dev/reference/rules/components-and-hooks-must-be-pure#how-does-react-run-your-code, it says:

After rendering, Effects are flushed (meaning they are run until there are no more left) and may update the calculation if the Effects have impacts on layout. React takes this new calculation and compares it to the calculation used to create the previous version of your UI, then commits just the minimum changes needed to the DOM (what your user actually sees) to catch it up to the latest version.

I think their explanation about when effects will run conflicts with each other. Looks like the former one says effects run after commit, but the latter two says effects run after render, and when these effects finish taking affects, React then enters the commit phase.

This is a bit confusing for me. Maybe one of them gives wrong explanation?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.