Hot Reload: muat ulang panas dan bagaimana mempercepat pengembangan

Apa itu Hot Reload?

Hot Reload — adalah mekanisme pengembangan di mana perubahan pada file sumber segera tercermin dalam aplikasi yang berjalan tanpa memulai ulang. Pengembang mengedit kode di editor, menyimpan file, dan hasilnya langsung terlihat di browser atau emulator.

Properti utama teknologi ini adalah mempertahankan status aplikasi. Variabel dalam memori, data dalam formulir, navigasi saat ini — semuanya tetap di tempatnya. Pengembang tidak perlu mengulangi urutan tindakan untuk kembali ke layar yang diperlukan.

Dalam pengembangan web, Hot Reload diimplementasikan melalui mekanisme Hot Module Replacement (HMR). Bundler melacak perubahan file, menentukan modul mana yang terpengaruh, dan mengirimkan kode yang diperbarui ke browser melalui WebSocket. Browser hanya mengganti modul tersebut tanpa memuat ulang halaman.

Popularitas Hot Reload melonjak dengan penyebaran aplikasi halaman tunggal (SPA), di mana muat ulang halaman penuh menghancurkan seluruh status aplikasi klien. React, Vue, Angular dan framework lainnya merekomendasikan HMR sebagai mode pengembangan utama.

Bagaimana HMR bekerja di dalam bundler

Mekanisme HMR terdiri dari empat tahap. Bundler di sisi server mengkompilasi modul yang dimodifikasi, membuat patch JSON dengan versi kode baru dan mengirimkannya ke browser melalui koneksi WebSocket. Bagian browser HMR runtime menerima patch, mengganti modul lama dengan yang baru dan memberi tahu pelanggan modul.

Tahap kompilasi dan pengiriman

Webpack Dev Server menggunakan WebSocket untuk komunikasi dengan klien. Saat file berubah, bundler membuat hot-update.js dan hot-update.json dengan manifes perubahan. Klien secara otomatis memuat file-file ini melalui JSONP.

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

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

Penerapan modul di klien

HMR runtime di browser memeriksa apakah modul yang diganti mendukung accept. Jika modul mendeklarasikan module.hot.accept(), runtime menggantinya di tempat dan menjalankan callback pembaruan. Jika accept tidak dideklarasikan, HMR turun ke tingkat yang lebih tinggi, ke modul induk.

Di React Fast Refresh logika ini dibangun di tingkat framework — tidak perlu menulis module.hot.accept secara manual di setiap file. Babel-plugin react-refresh/babel menambahkan kode yang dengan aman mengganti komponen tanpa kehilangan status.

Perbedaan Hot Reload dengan Live Reload dan Full Reload

Ketiga istilah ini sering membingungkan, tetapi sangat berbeda dalam perilaku. Live Reload memuat ulang seluruh halaman pada setiap perubahan — semua status hilang. Full Reload terjadi saat memulai ulang server pengembangan sepenuhnya dengan kehilangan tidak hanya status klien tetapi juga status server.

Pilihan antara Hot dan Live secara langsung mempengaruhi kecepatan pengembangan. Pada HMR, siklus ‘mengubah kode → melihat hasil’ memakan waktu 50-200 ms. Pada Live Reload — 1-3 detik ditambah waktu pemulihan konteks. Sepanjang hari kerja, perbedaannya mencapai puluhan menit waktu yang dihemat.

React Fast Refresh: fitur untuk React

React Fast Refresh — implementasi resmi Hot Reload yang dioptimalkan untuk komponen React. Ini menggantikan mekanisme React Hot Loader lama yang tidak stabil dan memerlukan konfigurasi manual. Fast Refresh dibangun di Create React App, Next.js, Vite dan Webpack melalui react-refresh/babel.

Dukungan untuk komponen fungsional

Fast Refresh dengan benar mempertahankan status komponen fungsional saat kode mereka berubah. Jika Anda hanya mengubah markup JSX — useState dan hook lainnya mempertahankan nilainya. Jika logika hook berubah — terjadi pemasangan ulang komponen.

// Contoh - status dipertahankan saat JSX berubah
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>
  );
}

Aturan penggantian yang aman

Fast Refresh tidak mempertahankan status jika kode baru mengandung kesalahan kompilasi. Jika komponen tidak diekspor secara default (named export), status juga mungkin tidak dipertahankan. Disarankan menggunakan default export untuk komponen dan membungkus ekspor dalam memo jika perlu menjamin pemertahanan status.

Alat build dengan dukungan HMR

Bundler modern menyediakan HMR. Webpack — pionir HMR dengan konfigurasi fleksibel melalui devServer.hot. Vite menggunakan ESM asli dan esbuild untuk HMR instan tanpa bundling. Parcel — HMR tanpa konfigurasi. Turbopack — bundler baru dari Vercel dengan HMR di Rust.

Vite menonjol dalam kecepatan — HMR di Vite bekerja melalui modul ES asli browser. Saat file berubah, Vite hanya mengirimkan modul tersebut melalui import(), tanpa mengkompilasi ulang seluruh proyek. Webpack mengkompilasi setiap modul sepenuhnya, yang memperlambat HMR di proyek besar.

Contoh konfigurasi HMR di proyek

Mari kita lihat konfigurasi HMR untuk berbagai bundler. Di Webpack perlu mengatur hot: true di devServer dan menambahkan react-refresh/babel. Di Vite HMR langsung jadi dengan preset apa pun. Di Next.js Fast Refresh diaktifkan secara default melalui turbokompiler.

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

Keterbatasan dan masalah muat ulang panas

HMR tidak berfungsi dengan benar dalam semua skenario. Modul CSS dengan kelas dinamis mungkin tidak diterapkan. Variabel global dan singleton (Redux store, router) dapat direset saat memuat ulang. Pustaka berat pada HMR terkadang menghasilkan kebocoran memori karena penggantian modul tanpa GC.

Solusi masalah HMR — isolasi kode panas dalam komponen murni tanpa efek samping. Efek samping (langganan WebSocket, timer) harus dibersihkan di useEffect. Untuk Redux disarankan persister yang menyimpan status di sessionStorage. Solusi CSS seperti CSS Modules atau styled-components bekerja dengan benar dengan HMR tanpa konfigurasi tambahan.

Keterbatasan lain — debugging di produksi: HMR sengaja dimatikan di build produksi. Kode sumber diminifikasi dan penggantian panas di produksi tidak mungkin dilakukan. Untuk debugging kesalahan di produksi gunakan source maps dan logging, bukan HMR.