react-native-website

Added documentation for fontVariationSettings property.

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 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 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.

Basically https://github.com/react/react-native-website/issues/1529 from 2019 which was closed due to inactivity. Related: https://github.com/react/react-native-website/pull/2634 which attempted to address this but unfortunately received no attention. Description The second example at https://reactnative.dev/docs/flatlist#example is introduced with By passing to we make sure itself will re-render when the state changes. Without setting this prop, would not know it needs to re-render any items because it is a PureComponent and the prop comparison will not show any changes. But if you delete the prop everything works fine. Since closes over , it is recreated whenever changes (or on every single render if the react compiler is disabled), hence receives a new prop and re-renders properly as you'd expect. Which makes me wonder: is there ever a need for ? Was it once necessary (perhaps in class component days, or old react native architecture) and is no longer needed? I'm struggling to think of a scenario in which it's needed, other than an escape hatch for syncing with something outside react, or to opt back in to reactivity after making manual memoizations. Currently the docs suggest it's necessary to make basic reactivity work, which is confusing. Documentation version 0.87