Hot Reload: gorące przeładowanie i jak przyspiesza programowanie

Co to jest Hot Reload?

Hot Reload — to mechanizm programowania, w którym zmiany w plikach źródłowych są natychmiast odzwierciedlane w działającej aplikacji bez jej ponownego uruchamiania. Programista edytuje kod w edytorze, zapisuje plik, a wynik jest natychmiast widoczny w przeglądarce lub emulatorze.

Kluczową właściwością technologii jest zachowanie stanu aplikacji. Zmienne w pamięci, dane w formularzach, bieżąca nawigacja — wszystko pozostaje na swoim miejscu. Programista nie musi powtarzać sekwencji działań, aby wrócić do potrzebnego ekranu.

W programowaniu internetowym Hot Reload jest realizowany poprzez mechanizm Hot Module Replacement (HMR). Bundler śledzi zmiany plików, określa, które moduły są dotknięte, i wysyła zaktualizowany kod do przeglądarki przez WebSocket. Przeglądarka zastępuje tylko te moduły bez przeładowania strony.

Popularność Hot Reload wzrosła wraz z rozpowszechnieniem aplikacji jednostronicowych (SPA), gdzie pełne przeładowanie strony niszczy cały stan aplikacji klienckiej. React, Vue, Angular i inne frameworki zalecają HMR jako podstawowy tryb programowania.

Jak działa HMR wewnątrz bundlera

Mechanizm HMR składa się z czterech etapów. Bundler po stronie serwera kompiluje zmodyfikowany moduł, tworzy JSON-łatkę z nową wersją kodu i wysyła ją do przeglądarki przez połączenie WebSocket. Część przeglądarkowa HMR runtime przyjmuje łatkę, zastępuje stary moduł nowym i powiadamia subskrybentów modułu.

Etap kompilacji i wysyłania

Webpack Dev Server używa WebSocket do komunikacji z klientem. Przy zmianie pliku bundler tworzy hot-update.js i hot-update.json z manifestem zmian. Klient automatycznie ładuje te pliki przez JSONP.

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

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

Zastosowanie modułu na kliencie

HMR runtime w przeglądarce sprawdza, czy zastępowany moduł obsługuje accept. Jeśli moduł zadeklarował module.hot.accept(), runtime zastępuje go in-place i uruchamia callback aktualizacji. Jeśli accept nie jest zadeklarowany, HMR spada do poziomu wyższego, do modułu nadrzędnego.

W React Fast Refresh ta logika jest wbudowana na poziomie frameworka — nie trzeba ręcznie pisać module.hot.accept w każdym pliku. Babel-plugin react-refresh/babel dodaje kod, który bezpiecznie zastępuje komponenty bez utraty stanu.

Różnica między Hot Reload a Live Reload i Full Reload

Te trzy terminy są często mylone, ale radykalnie różnią się zachowaniem. Live Reload przeładowuje całą stronę przy każdej zmianie — cały stan jest tracony. Full Reload następuje przy pełnym ponownym uruchomieniu serwera programistycznego z utratą nie tylko stanu klienckiego, ale i serwerowego.

Wybór między Hot a Live bezpośrednio wpływa na szybkość programowania. Przy HMR cykl „zmieniłem kod → zobaczyłem wynik” zajmuje 50-200 ms. Przy Live Reload — 1-3 sekundy plus czas na przywrócenie kontekstu. W ciągu dnia roboczego różnica wynosi dziesiątki minut zaoszczędzonego czasu.

React Fast Refresh: funkcje dla React

React Fast Refresh — oficjalna implementacja Hot Reload zoptymalizowana dla komponentów React. Zastąpiła stary mechanizm React Hot Loader, który był niestabilny i wymagał ręcznej konfiguracji. Fast Refresh jest wbudowany w Create React App, Next.js, Vite i Webpack przez react-refresh/babel.

Obsługa komponentów funkcyjnych

Fast Refresh poprawnie zachowuje stan komponentów funkcyjnych przy zmianie ich kodu. Jeśli zmieniasz tylko znaczniki JSX — useState i inne hooki zachowują swoje wartości. Jeśli zmienia się logika hooka — następuje ponowne zamontowanie komponentu.

// Przykład - stan zachowany przy zmianach JSX
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>
  );
}

Zasady bezpiecznej zamiany

Fast Refresh nie zachowuje stanu, jeśli nowy kod zawiera błąd kompilacji. Jeśli komponent nie jest eksportowany domyślnie (named export), stan również może nie zostać zachowany. Zaleca się używanie default export dla komponentów i owijanie eksportów w memo, jeśli trzeba zagwarantować zachowanie stanu.

Narzędzia do budowania z obsługą HMR

Nowoczesne bundlery zapewniają HMR. Webpack — pionier HMR z elastyczną konfiguracją przez devServer.hot. Vite używa natywnego ESM i esbuild do błyskawicznego HMR bez bundlingu. Parcel — zero-config HMR. Turbopack — nowy bundler od Vercel z HMR na Rust.

Vite wyróżnia się szybkością — HMR w Vite działa przez natywne ES-moduły przeglądarki. Przy zmianie pliku Vite wysyła tylko ten moduł przez import(), bez rekompilacji całego projektu. Webpack kompiluje każdy moduł w całości, co przy dużych projektach spowalnia HMR.

Przykłady konfiguracji HMR w projektach

Rozważmy konfigurację HMR dla różnych bundlerów. W Webpack należy ustawić hot: true w devServer i dodać react-refresh/babel. W Vite HMR działa od razu z dowolnym presetem. W Next.js Fast Refresh jest włączony domyślnie przez turbokompilator.

Vite z 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 z 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'
      }
    ]
  }
};

Ograniczenia i problemy gorącego przeładowania

HMR nie działa poprawnie we wszystkich scenariuszach. Moduły CSS z dynamicznymi klasami mogą nie zostać zastosowane. Zmienne globalne i singletonowe (Redux store, router) mogą się zresetować przy przeładowaniu. Ciężkie biblioteki przy HMR czasami generują wycieki pamięci z powodu wymiany modułów bez GC.

Rozwiązanie problemów HMR — wyizolować gorący kod w czyste komponenty bez efektów ubocznych. Efekty uboczne (subskrypcje WebSocket, timery) powinny być czyszczone w useEffect. Dla Redux zaleca się persister, zapisujący stan w sessionStorage. Rozwiązania CSS, takie jak CSS Modules czy styled-components, działają poprawnie z HMR bez dodatkowej konfiguracji.

Kolejne ograniczenie — debugowanie w produkcji: HMR jest celowo wyłączany w kompilacji produkcyjnej. Kod źródłowy jest minifikowany, a gorąca zamiana na produkcji jest niemożliwa. Do debugowania błędów na produkcji używa się source maps i logowania, ale nie HMR.