Hot Module Replacement (HMR)
A dev server swaps changed code into the running page, often preserving UI state instead of doing a full reload.
What it is
Hot Module Replacement lets a development server send only a changed module to the browser and replace the old version without reloading the document. webpack introduced HMR to the mainstream and Dan Abramov's react-hot-loader made it a React habit. Today Vite exposes the low-level import.meta.hot API, while React Fast Refresh sits on top and tries to preserve component state when an edit is safe.
Reach for it during local development when a full reload would reset a form, close a modal, or make a slow route boot again. CSS is especially easy to swap live. JavaScript modules need an accepted update boundary, and framework plugins usually create those boundaries for components so application code rarely handles HMR directly.
HMR is not guaranteed state preservation and it is not a production delivery system. Changing a component's shape or editing a module outside an accepted boundary can force a full reload. Module-scope timers, sockets, and event listeners can also duplicate across updates unless the old module disposes them. Fast feedback is useful only if a clean reload and production build still work.
Ask AI for it
Add HMR to this Vite React development setup with @vitejs/plugin-react and React Fast Refresh. Keep component modules as valid refresh boundaries, use import.meta.hot.accept for the custom data module, and register import.meta.hot.dispose cleanup for its timer and WebSocket. Confirm that editing a component preserves form state, editing CSS updates in place, and an unsupported change falls back to a full reload.