Hot Reload: het omstart och hur det snabbar upp utvecklingen

Vad är Hot Reload?

Hot Reload — är en utvecklingsmekanism där ändringar i källfiler omedelbart reflekteras i den körande applikationen utan omstart. Utvecklaren redigerar kod i editorn, sparar filen och resultatet syns direkt i webbläsaren eller emulatorn.

Den viktigaste egenskapen hos tekniken är bevarandet av applikationens tillstånd. Variabler i minnet, data i formulär, aktuell navigering — allt förblir på sin plats. Utvecklaren behöver inte upprepa sekvensen av åtgärder för att återvända till önskad skärm.

I webbutveckling implementeras Hot Reload genom mekanismen Hot Module Replacement (HMR). Bundlaren övervakar filändringar, avgör vilka moduler som påverkas och skickar den uppdaterade koden till webbläsaren via WebSocket. Webbläsaren ersätter endast dessa moduler utan att ladda om sidan.

Populariteten för Hot Reload ökade med spridningen av ensidiga applikationer (SPA), där full omstart av sidan förstör hela klientapplikationens tillstånd. React, Vue, Angular och andra ramverk rekommenderar HMR som primärt utvecklingsläge.

Hur fungerar HMR inuti bundlaren

HMR-mekanismen består av fyra steg. Bundlaren på serskidan kompilerar den ändrade modulen, skapar en JSON-lapp med den nya kodversionen och skickar den till webbläsaren via WebSocket-anslutning. Webbläsardelen av HMR runtime tar emot lappen, ersätter den gamla modulen med den nya och meddelar modulens prenumeranter.

Kompilerings- och sändningssteget

Webpack Dev Server använder WebSocket för kommunikation med klienten. Vid filändring skapar bundlaren hot-update.js och hot-update.json med en manifest av ändringar. Klienten laddar automatiskt dessa filer via JSONP.

// webpack.config.js - HMR-installation
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'development',
  devServer: {
    hot: true,
    liveReload: false
  },
  plugins: [new HtmlWebpackPlugin()]
};

Tillämpning av modulen på klienten

HMR runtime i webbläsaren kontrollerar om den ersatta modulen stöder accept. Om modulen har deklarerat module.hot.accept(), ersätter runtime den på plats och kör uppdateringscallbacken. Om accept inte har deklarerats, faller HMR till en högre nivå, till den överordnade modulen.

I React Fast Refresh är denna logik inbyggd på ramverksnivå — det finns inget behov av att manuellt skriva module.hot.accept i varje fil. Babel-plugin react-refresh/babel lägger till kod som säkert ersätter komponenter utan tillståndsförlust.

Skillnad mellan Hot Reload, Live Reload och Full Reload

Dessa tre termer blandas ofta ihop, men skiljer sig radikalt i beteende. Live Reload laddar om hela sidan vid varje ändring — allt tillstånd går förlorat. Full Reload inträffar vid full omstart av utvecklingsservern med förlust av inte bara klientens tillstånd utan även serverns tillstånd.

Valet mellan Hot och Live påverkar direkt utvecklingshastigheten. Vid HMR tar cykeln ”ändrade koden → såg resultatet” 50-200 ms. Vid Live Reload — 1-3 sekunder plus tid för kontextåterställning. Under en arbetsdag innebär skillnaden tiotals minuter sparad tid.

React Fast Refresh: funktioner för React

React Fast Refresh — den officiella implementeringen av Hot Reload optimerad för React-komponenter. Den ersatte den gamla mekanismen React Hot Loader, som var instabil och krävde manuell konfiguration. Fast Refresh är inbyggt i Create React App, Next.js, Vite och Webpack via react-refresh/babel.

Stöd för funktionella komponenter

Fast Refresh bevarar korrekt tillståndet för funktionella komponenter när deras kod ändras. Om du endast ändrar JSX-markup — useState och andra hooks behåller sina värden. Om hookens logik ändras — sker ommontering av komponenten.

// Exempel - tillstånd bevaras när JSX ändras
import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </div>
  );
}

Regler för säker ersättning

Fast Refresh bevarar inte tillståndet om den nya koden innehåller kompileringsfel. Om komponenten inte exporteras som standard (named export), kan tillståndet också gå förlorat. Det rekommenderas att använda default export för komponenter och slå in exporter i memo om tillståndsbevarande behöver garanteras.

Byggverktyg med HMR-stöd

Moderna bundlare erbjuder HMR. Webpack — pionjär inom HMR med flexibel konfiguration via devServer.hot. Vite använder inbyggd ESM och esbuild för omedelbar HMR utan bundling. Parcel — HMR utan konfiguration. Turbopack — den nya bundlaren från Vercel med HMR på Rust.

Vite utmärker sig i hastighet — HMR i Vite fungerar via webbläsarens inbyggda ES-moduler. Vid filändring skickar Vite endast den modulen via import(), utan att kompilera om hela projektet. Webpack kompilerar varje modul i sin helhet, vilket saktar ner HMR i stora projekt.

Exempel på HMR-konfiguration i projekt

Låt oss titta på HMR-konfiguration för olika bundlare. I Webpack måste du ställa in hot: true i devServer och lägga till react-refresh/babel. I Vite fungerar HMR direkt ur lådan med vilket preset som helst. I Next.js är Fast Refresh aktiverat som standard via turbokompilatorn.

Vite med React

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  server: {
    hmr: {
      port: 3001
    }
  }
});

Webpack 5 med Fast Refresh

// webpack.config.js
const ReactRefreshWebpackPlugin =
  require('@pmmmwh/react-refresh-webpack-plugin');

module.exports = {
  mode: 'development',
  devServer: { hot: true },
  plugins: [new ReactRefreshWebpackPlugin()],
  module: {
    rules: [
      {
        test: /\.jsx?$/u,
        use: 'babel-loader'
      }
    ]
  }
};

Begränsningar och problem med het omstart

HMR fungerar inte korrekt i alla scenarier. CSS-moduler med dynamiska klasser kan eventuellt inte tillämpas. Globala variabler och singletons (Redux store, router) kan återställas vid omstart. Tunga bibliotek vid HMR genererar ibland minnesläckor på grund av modulbyte utan GC.

Lösningen på HMR-problem — isolera het kod i rena komponenter utan biverkningar. Biverkningar (WebSocket-prenumerationer, timers) bör rensas i useEffect. För Redux rekommenderas en persister som sparar tillstånd i sessionStorage. CSS-lösningar som CSS Modules eller styled-components fungerar korrekt med HMR utan extra konfiguration.

En annan begränsning — felsökning i produktion: HMR är avsiktligt avaktiverat i produktionsbyggen. Källkoden är minifierad och het ersättning i produktion är omöjlig. För felsökning av fel i produktion används source maps och loggning, men inte HMR.