"[vite] hot updated" fires but React component state resets on every edit — Fast Refresh boundary issue?

Question

I'm seeing a consistent behavior in a Vite dev server setup where HMR appears to work — the console logs the hot update event and no full page reload occurs — yet the edited React component loses all of its local state on every save. My understanding is that Fast Refresh should preserve component state across edits when the module is structured correctly.

From the documentation, Fast Refresh relies on a file exporting only React components (or components plus hooks) for state preservation to work. My component file also exports a couple of plain utility constants and a non-component helper function, and I suspect this mixed export pattern is what forces a fallback that remounts the component instead of refreshing it.

Relevant constraints: this is on Vite 5.x with the official React plugin, and I know HMR behavior around CSS and side-effectful modules changed between major versions, so I want to be sure I'm reasoning about the current semantics. The module does not call import.meta.hot.accept() manually.

My questions:

Does mixing non-component exports with component exports in one file definitively disable state-preserving Fast Refresh for that module in Vite 5.x?
Is there a documented way to confirm at runtime whether a given module qualified for Fast Refresh versus falling back to a remount?
Would adding an explicit import.meta.hot.accept() handler change this behavior, or does the React plugin override it?

Tasadduq Burney · Answer

Direct answers

Yes. In Vite 5.x with @vitejs/plugin-react, exporting anything besides a React component (or hooks) from the same file disables the Fast Refresh acceptance path, causing a full remount and loss of local state.
There is no built‑in runtime flag to query the acceptance mode. The only observable cue is the console message [Fast Refresh] that appears when a module is accepted via Fast Refresh; its absence indicates a fallback remount.
Adding a manual import.meta.hot.accept() handler does not override the plugin’s internal logic; the React plugin replaces or ignores custom handlers, so it will not change the fallback behavior.

Confirmed facts

React Fast Refresh documentation states that state is preserved only when a module’s exports consist solely of React components (or hooks).
The official @vitejs/plugin-react for Vite 5.x follows the same rule; mixed exports trigger a remount.
No API exists to ask the plugin whether a module was accepted via Fast Refresh.

Likely explanation
Your component file exports a React component together with plain constants and a helper function. Because the module contains non‑component exports, the plugin treats the whole module as ineligible for Fast Refresh, falls back to a remount, and re‑initializes all useState, useReducer, and useRef values on each save.
Steps to verify and fix

Open the browser console, save a change to the component, and look for the line [Fast Refresh]. If you do not see it, the module is being remounted.
Move the utility constants and helper function to a separate file (e.g., utils.js) and import them where needed.
Ensure the component file now exports only the React component (and any hooks it uses).
Save again; you should see the [Fast Refresh] message and the component’s local state should persist.

If you are not seeing the [Fast Refresh] message after making the change, let me know whether any other HMR‑related logs appear; that detail would affect whether we need to investigate plugin version or side‑effectful imports.

"[vite] hot updated" fires but React component state resets on every edit — Fast Refresh boundary issue?

1 answer

Direct answers

Confirmed facts

Likely explanation

Steps to verify and fix

Your perspective belongs here.

0 question comments