[Suggestion]: More concrete advice for writing Fast Refresh-compatible code

Summary

I'm seeking advice on writing code that is compatible with React Fast Refresh and drawing a bit of a blank. I found: https://reactnative.dev/docs/fast-refresh (NB reactnative.dev not react.dev) which has some tips but the information is not very formal.

Should the react docs contain clear information about how to structure your code for best compatibility with Fast Refresh?

Page

No response

Details

From what I've gathered, it's recommended that any file exporting a React component should not export anything else (e.g., utility functions, data) to ensure Fast Refresh functions properly, and I found eslint-plugin-react-refresh which exists to help enforce this rule.

I was surprised not to be able to find authoritative guidance on this in the official react docs.

• Is the advice I've seen in forums etc. correct, i.e. to export only 1 react component per file?
• Do the rules in eslint-plugin-react-refresh accurately reflect best practice as it stands in 2025?
• Should the react docs be more clear on what exactly is best practice in this respect?

(For background, I had to fix a number of issues when migrating our codebase (a few 10,000s loc) from preact to react and during this came across the plugin https://github.com/ArnaudBarre/eslint-plugin-react-refresh which I then enabled, which throws up many errors in our codebase (react/vite). I asked two experienced react developers if they comply with the rules as suggested by eslint-plugin-react-refresh and they seemed perplexed, suggesting that people don't structure things this way in real codebases — admittedly this is the most informal possible polling, but I couldn't point them to any particularly authoritative info to the contrary.)

As always, apologies if I have simply missed the relevant info in the docs.

Review the linked React Native Fast Refresh guidance and eslint-plugin-react-refresh, then determine what authoritative advice the React documentation should provide. Done means agreeing on the recommended code-structure guidance and defining the documentation content or page changes needed.