reactjs / reactjs/react.dev

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

Abierto
#7,801 2 comentarios 0 reacciones 1 asignado Ver en GitHub

@poteto ya está trabajando en esto.

Desde el 16/5/2025.

type: typos
Lenguaje dominante
JavaScript
Estrellas
11.8k
Forks
7.9k
Merge medio
1 d 11 h
PR fusionados (30 d)
11

Descripción

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?

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.