reactjs / reactjs/react.dev

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

Aberta
#7,801 2 comentários 0 reações 1 responsável Ver no GitHub

@poteto já está trabalhando nisso.

Desde 16/5/2025.

type: typos
Linguagem predominante
JavaScript
Estrelas
11.8k
Forks
7.9k
Merge médio
1d 11h
PRs com merge (30d)
11

Descrição

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?

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.