Hot Reload: mainit na pag-reload at kung paano nito pinapabilis ang pag-develop

Ano ang Hot Reload?

Hot Reload — ay isang mekanismo ng pag-develop kung saan ang mga pagbabago sa source file ay agad na naipapakita sa tumatakbong application nang hindi ito nire-restart. Ang developer ay nag-eedit ng code sa editor, nagse-save ng file, at ang resulta ay agad na nakikita sa browser o emulator.

Ang pangunahing katangian ng teknolohiya ay ang pagpapanatili ng estado ng application. Ang mga variable sa memorya, data sa mga form, kasalukuyang navigation — lahat ay nananatili sa lugar. Ang developer ay hindi kailangang ulitin ang pagkakasunod-sunod ng mga aksyon para bumalik sa kinakailangang screen.

Sa web development, ang Hot Reload ay ipinapatupad sa pamamagitan ng mekanismong Hot Module Replacement (HMR). Sinusubaybayan ng bundler ang mga pagbabago sa file, tinutukoy kung aling mga module ang apektado, at ipinapadala ang updated na code sa browser sa pamamagitan ng WebSocket. Ang browser ay nagpapalit lamang ng mga module na iyon nang hindi nire-reload ang pahina.

Tumaas ang kasikatan ng Hot Reload sa paglaganap ng single-page applications (SPA), kung saan ang buong pag-reload ng pahina ay sumisira sa buong estado ng client application. Ang React, Vue, Angular at iba pang frameworks ay nagrerekomenda ng HMR bilang pangunahing development mode.

Paano gumagana ang HMR sa loob ng bundler

Ang mekanismo ng HMR ay binubuo ng apat na yugto. Ang bundler sa panig ng server ay nagko-compile ng binagong module, gumagawa ng JSON patch na may bagong bersyon ng code at ipinapadala ito sa browser sa pamamagitan ng WebSocket connection. Ang bahagi ng browser na HMR runtime ay tumatanggap ng patch, pinapalitan ang lumang module ng bago at inaabisuhan ang mga subscriber ng module.

Yugto ng compilation at pagpapadala

Ang Webpack Dev Server ay gumagamit ng WebSocket para sa komunikasyon sa client. Kapag nagbago ang file, gumagawa ang bundler ng hot-update.js at hot-update.json na may manifest ng mga pagbabago. Ang client ay awtomatikong naglo-load ng mga file na ito sa pamamagitan ng JSONP.

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

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

Paglalapat ng module sa client

Sinusuri ng HMR runtime sa browser kung ang pinalitang module ay sumusuporta sa accept. Kung ang module ay nagdeklara ng module.hot.accept(), pinapalitan ito ng runtime in-place at pinapatakbo ang update callback. Kung hindi nadeklara ang accept, bababa ang HMR sa mas mataas na antas, sa parent module.

Sa React Fast Refresh ang lohikang ito ay built-in sa antas ng framework — hindi na kailangang magsulat ng module.hot.accept sa bawat file nang manu-mano. Ang Babel-plugin react-refresh/babel ay nagdaragdag ng code na ligtas na nagpapalit ng mga component nang walang pagkawala ng estado.

Pagkakaiba ng Hot Reload sa Live Reload at Full Reload

Ang tatlong terminong ito ay madalas na napagkakamalan, ngunit lubos na naiiba sa pag-uugali. Ang Live Reload ay nagre-reload ng buong pahina sa bawat pagbabago — lahat ng estado ay nawawala. Ang Full Reload ay nangyayari sa buong pag-restart ng development server na may pagkawala hindi lamang ng client state, kundi pati na rin ng server state.

Ang pagpili sa pagitan ng Hot at Live ay direktang nakakaapekto sa bilis ng pag-develop. Sa HMR, ang cycle na ‘binago ang code → nakita ang resulta’ ay tumatagal ng 50-200 ms. Sa Live Reload — 1-3 segundo at oras para sa pagpapanumbalik ng konteksto. Sa buong araw ng trabaho, ang pagkakaiba ay sampu-sampung minuto ng nai-save na oras.

React Fast Refresh: mga feature para sa React

React Fast Refresh — opisyal na implementasyon ng Hot Reload na na-optimize para sa React components. Pinalitan nito ang lumang mekanismo ng React Hot Loader, na hindi matatag at nangangailangan ng manu-manong configuration. Ang Fast Refresh ay built-in sa Create React App, Next.js, Vite at Webpack sa pamamagitan ng react-refresh/babel.

Suporta para sa functional components

Tama na pinapanatili ng Fast Refresh ang estado ng functional components kapag nagbago ang kanilang code. Kung babaguhin mo lamang ang JSX markup — useState at iba pang hooks ay nagpapanatili ng kanilang mga halaga. Kung magbabago ang logika ng hook — magaganap ang muling pag-mount ng component.

// Halimbawa - napanatili ang estado kapag nagbago ang 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>
  );
}

Mga panuntunan ng ligtas na pagpapalit

Hindi pinapanatili ng Fast Refresh ang estado kung ang bagong code ay naglalaman ng error sa compilation. Kung ang component ay hindi na-export bilang default (named export), ang estado ay maaari ring hindi mapanatili. Inirerekomenda ang paggamit ng default export para sa mga component at pagbabalot ng mga export sa memo kung kailangan garantiya ang pagpapanatili ng estado.

Mga tool sa pag-build na may suporta sa HMR

Ang mga modernong bundler ay nagbibigay ng HMR. Webpack — pioneer ng HMR na may flexible configuration sa pamamagitan ng devServer.hot. Vite ay gumagamit ng native ESM at esbuild para sa instant HMR nang walang bundling. Parcel — zero-config HMR. Turbopack — bagong bundler mula sa Vercel na may HMR sa Rust.

Namumukod-tangi ang Vite sa bilis — ang HMR sa Vite ay gumagana sa pamamagitan ng native ES modules ng browser. Kapag nagbago ang file, ang Vite ay nagpapadala lamang ng module na iyon sa pamamagitan ng import(), nang hindi nire-recompile ang buong proyekto. Ang Webpack ay nagco-compile ng bawat module nang buo, na nagpapabagal ng HMR sa malalaking proyekto.

Mga halimbawa ng configuration ng HMR sa mga proyekto

Tingnan natin ang configuration ng HMR para sa iba't ibang bundler. Sa Webpack kailangan mong itakda ang hot: true sa devServer at idagdag ang react-refresh/babel. Sa Vite ang HMR ay agad-agad na gumagana sa anumang preset. Sa Next.js ang Fast Refresh ay naka-enable bilang default sa pamamagitan ng turbocompiler.

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

Mga limitasyon at problema ng mainit na pag-reload

Ang HMR ay hindi gumagana nang tama sa lahat ng senaryo. Ang CSS modules na may dynamic na klase ay maaaring hindi mailapat. Ang global variables at singleton (Redux store, router) ay maaaring ma-reset sa pag-reload. Ang mabibigat na library sa HMR minsan ay nagdudulot ng memory leaks dahil sa pagpapalit ng module nang walang GC.

Solusyon sa mga problema ng HMR — ihiwalay ang mainit na code sa purong component na walang side effects. Ang side effects (subscription sa WebSocket, timer) ay dapat linisin sa useEffect. Para sa Redux inirerekomenda ang persister na nagse-save ng estado sa sessionStorage. Ang mga solusyong CSS tulad ng CSS Modules o styled-components ay gumagana nang tama sa HMR nang walang karagdagang configuration.

Isa pang limitasyon — debugging sa production: ang HMR ay sadyang naka-off sa production build. Ang source code ay minified at ang mainit na pagpapalit sa production ay imposible. Para sa debugging ng mga error sa production ay gumagamit ng source maps at logging, hindi HMR.