Docs: distinguish Fast Refresh effect reruns from Strict Mode checks
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 1/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 88/100
- Tipo di issue
- Documentazione
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- react, react-native
- Ambito
- documentation
Direzione di ricerca
Inizia in docs/fast-refresh.md, vicino alla sezione «Fast Refresh and Hooks», poi leggi il riferimento collegato a React Strict Mode. Aggiungi una breve precisazione che distingua Fast Refresh dopo una modifica al codice dal ciclo di setup e cleanup di Effect, previsto solo in sviluppo, di Strict Mode. Il lavoro è completato quando la distinzione e le indicazioni sul cleanup sono chiare, senza modificare la spiegazione esistente di Fast Refresh.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
The Fast Refresh page correctly explains that Hooks with dependencies update during a refresh and that even an Effect with an empty dependency list can run again after an edit.
A short clarification could help readers distinguish that behavior from React Strict Mode's separate development-only Effect check.
What is the problem?
When Strict Mode is enabled, developers can observe repeated Effect setup and cleanup without having triggered a Fast Refresh. Because both mechanisms occur during development and both reward resilient Effect cleanup, their output is easy to conflate while debugging.
The triggers and behavior are different:
- Fast Refresh follows a code edit and temporarily ignores dependency lists so the edited Hook logic is applied.
- Strict Mode independently performs an extra development-only Effect setup and cleanup cycle to reveal missing cleanup.
Without that distinction, a developer may incorrectly attribute every repeated Effect to Fast Refresh.
How can we address it?
Add a short note near the end of “Fast Refresh and Hooks,” using the official React Strict Mode documentation as the primary reference.
Possible wording:
Fast Refresh is not the only reason an Effect may run again during development. When Strict Mode is enabled at the application root, React performs an additional development-only setup and cleanup cycle to help find missing cleanup. Fast Refresh reruns Hooks after a code edit, whereas the Strict Mode check can occur on initial mounting without a file save. In both cases, Effects should implement complete cleanup and tolerate being restarted.
Official reference:
https://react.dev/reference/react/StrictMode#fixing-bugs-found-by-re-running-effects-in-development
I can prepare a small docs-only PR against docs/fast-refresh.md if this distinction belongs on the page.
An optional public exercise illustrating the Strict Mode behavior is:
https://frontendatlas.com/react/trivia/react-strictmode-double-invoke-effects
That exercise is not required for the proposed correction; the official React documentation should remain the primary reference.
Why is it important?
It gives React Native developers a more precise debugging model for repeated subscriptions, requests, logs, and cleanup behavior, without weakening the existing guidance that Effects should be resilient.
Who needs this?
React Native developers using function components and Hooks, especially those diagnosing duplicated development-only Effect output.
When should this happen (use version numbers if needed)?
This is not tied to a specific React Native release. It can be made in the docs/fast-refresh.md source for the next documentation version; any current-version backport can remain a maintainer decision.
Disclosure
I maintain FrontendAtlas, an independent frontend interview-prep project, including the optional exercise linked above. No paid, sponsored, or affiliate placement is being requested. I used AI assistance to draft this issue and reviewed it for technical accuracy before posting.
- Lingua principale
- MDX
- Stelle
- 2.2k
- Fork
- 6.3k
- Merge medio
- 11h 37m
- PR unite (30g)
- 19
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di react/react-native-website
-
Integration with Existing Apps: Podfile example does not use `use_react_native!`, is incomplete Aperta👋 Good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
react/react-native-website#2958 · 2 commenti ·
-
:ghost: Missing Docs 👋 Good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
react/react-native-website#889 · 5 commenti · 1 reazione ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
react/react-native-website#5216 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 42/100
react/react-native-website#5154 · 6 commenti ·
-
Never gets stale
Difficoltà 2/5 1-3 ore Idoneità per principianti 38/100
react/react-native-website#4265 · 2 commenti ·
Tutte le issue di react/react-native-website
Issue simili
-
Crush Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
catppuccin/catppuccin#3125 ·
-
Link Checker Report Apertaautomated issue report
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 95/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
VoltAgent/awesome-design-md#469 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
KhronosGroup/glTF#2648 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
sccn/sccn.github.io#108 ·