Original translation, please indicate the source when reprinting.
Original address: https://webpack.js.org/concepts/hot-module-replacement/
Hot Module Replacement ( HMR ), used to change, add and delete modules in a running application without reloading the page. This makes it unnecessary to update the module by refreshing the page when changing a module, which improves the speed of development.
How does it work?
application point of view
- Application code requires runtime HMR to check for updates.
- The runtime HMR downloads the update (asynchronously) and tells the application code that an update was found.
- Application code requires runtime HMR implementation updates.
- Runtime HMR implementation (synchronous)
You can automate this process by setting up the HMR , or you can choose to request user interaction when an update occurs.
From a compiler ( webpack ) point of view
In addition to normal resources, the compiler needs to issue an " update " to implement an update from the old version to the new version. This " update " consists of two parts:
- Update manifest ( JSON )
- One or more update code blocks ( JavaScript )
The update manifest contains a new compile hash and a list of all updated code blocks.
Each update block contains the updated module (or an identifier indicating that the module was removed) that existed in the respective block.
The compiler ensures that the module ID and code block ID are the same during each build. It usually keeps these IDs in memory (for example, when using webpack-dev-server ), but can also store them in JSON files.
From a module point of view
HMR is an optional feature that only affects modules that contain HMR code. An example is importing styles through the style-loader . To make it work, the style-loader implements the HMR interface; when it receives an update via HMR , it replaces the old style with the new one.
Likewise, when a module implements the HMR interface, you can describe what should happen when an update occurs.
However, in most cases it is not mandatory to write HMR code in every module . If a module has no HMR handler, updates bubble up. This means that one handler can make updates to the complete module tree. If a module in the module tree is updated, the module tree is reloaded (only reloaded, not replaced)
From a runtime HMR viewpoint (technically)
For the module system runtime, additional code is generated to keep track of parent and child modules.
On the management side, the runtime supports two methods: check and apply
- Check makes an HTTP request to update the manifest . If the request fails, there is no update. If successful, compare the list of updated code blocks with the list of code blocks that have now been loaded. For each loaded code block, download the corresponding updated code block. All module updates are saved at runtime. When all updated code blocks have been downloaded and are ready to be implemented, the runtime transitions to the ready state.
- The apply method marks all updated modules as invalid. For each invalid module, an update handler in the module or in its parent module is required. Additionally, an invalid identifier bubbles up, making its parent module invalid as well. Each bubbling continues until the application's entry point, or to a module with an update handler (whichever happens first). If it bubbles up from the entry point, then the processing fails.
Then, all invalid modules are destroyed (via the destroy handler) and unloaded. Then update the current hash and call all accept handlers. The runtime switches back to the idle state, and everything continues normally.
What can I do with it?
Can be used in live reload / replace during development. webpack-dev-server supports a hot mode that tries to load the updated part using HMR before trying to reload the whole page . See the example of implementing HMR in React .
Some loaders already generate hot-updateable modules. For example, the style-loader can replace a page's stylesheet. With modules like this, you don't need to do anything special.
The power of Webpack lies in its customizability, and there are many ways to configure HMR depending on the needs of each project .
-- End --