reactjs / reactjs/react.dev

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

Aperta
#7,801 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@poteto ci sta già lavorando.

Dal 16/5/2025.

type: typos
Lingua principale
JavaScript
Stelle
11.8k
Fork
7.9k
Merge medio
1g 11h
PR unite (30g)
11

Descrizione

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?

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.