Fast Refresh state reset after editing unrelated UI text

The short answer

Fast Refresh does not decide whether to keep useState based on which line you edited. It decides based on whether the module still "looks like" a pure component module and whether the component's identity survives the update. If a text-only edit causes a state reset, the text itself is almost never the cause — the file was already in a state where any edit triggers a full reload, and the text change was just the first edit you made.

Likely explanation vs. confirmed facts

Confirmed, well-established behavior:

• Fast Refresh (via the React Refresh runtime) preserves state only when a file's exports are exclusively React components. A single extra export — a constant, a helper function, a config object — makes the module ineligible for state preservation, and every edit to that file forces a full remount.
• State is matched by component identity and position in the tree. Anonymous components, components defined inside other components, or components whose reference changes between renders will lose state on refresh.
• React Refresh requires a Babel transform (react-refresh/babel) that registers component signatures. Anything that interferes with that transform breaks the signature map.

Likely but not confirmed for your setup: Metro cache corruption, custom Babel plugins, or a version-specific regression. These are plausible contributors, but they are diagnoses to verify, not established causes. There is no documented "Metro cache condition" that selectively discards state on text edits — a poisoned cache typically causes stale modules or failed refreshes broadly, not surgical state loss.

Steps for this specific case

1. Check the file's exports first. If the edited file exports anything besides components (e.g. export const SOME_CONST, a navigation helper, a styles object), that alone explains the reset. Move the non-component export to its own file.
2. Check the component definition. Ensure it is a named function at module top level, not an arrow function created inline inside another component or passed through a HOC that returns a new type each render.
3. Test with a clean Metro cache to rule out cache state:

   npx react-native start --reset-cache

   or on Expo:

   npx expo start -c

   If the reset disappears after a cache clear but returns later, note what changed in between (dependency installs, Babel config edits).
4. Isolate Babel plugins. If babel.config.js includes custom plugins (codegen, module-resolver with unusual aliasing, anything injecting identifiers), disable them one at a time and re-test. Plugins that wrap or rename component functions prevent the React Refresh transform from registering a stable signature.
5. Confirm it's Fast Refresh, not a full reload. Watch the Metro logs: a "Fast Refresh" line means reconciliation was attempted; a full reload banner means the module was deemed ineligible entirely. This single observation splits the problem space in half.

Version ranges

Fast Refresh has been the default since React Native 0.61, and the core eligibility rules above have been stable since. Specific reconciliation bugs have appeared and been fixed across individual releases, but there is no verified version range that reproducibly resets state on static-text edits — treat any such claim with skepticism and pin it to a reproducible example before trusting it. Behavior also differs between Expo managed and bare workflows because they ship different Metro and Babel presets, so always report both your RN/Expo SDK version and workflow type when comparing notes.

One detail that would change the recommendation

Does the affected file export anything other than the component? If yes, that is the answer and no cache or plugin investigation is needed. If no, the next diagnostic is whether Metro logs a Fast Refresh or a full reload on the edit — share that and the Babel config.