Module thermal replacement (hot modules replacement)
The module Hot swap (Hmr-hot module replacement) feature replaces, adds, or removes modules while the application is running, without reloading the entire page. There are several ways to significantly speed up the development process:
- Leave the application state missing when the page is completely reloaded.
- Update only the changes to save valuable development time.
- Adjust styles more quickly-almost the equivalent of changing styles in the browser debugger.
How does all this work?
Let's look at some different angles to see how HMR works ...
in the application
The following steps allow you to displace (swap in and out) modules in your application:
- Application code requires HMR runtime to check for updates.
- HMR Runtime (asynchronously) downloads the update and then notifies the application code.
- Application code requires HMR Runtime app update.
- HMR Runtime (async) app update.
You can set HMR so that the process automatically triggers the update, or you can choose to require updates when the user interacts.
in the compiler
In addition to the normal resources, the compiler (compiler) needs to issue "update" to allow the previous version to be updated to the new version. "Update" consists of two parts:
- Updated manifest (JSON)
- One or more updated chunk (JavaScript)
Manifest includes the new compilation hash and all the chunk directories to be updated.
Each update chunk contains the code that corresponds to this chunk for all update modules (or a flag to indicate that the module is being removed).
The compiler ensures that the module ID and chunk ID are consistent between these constructs.
These IDs are typically stored in memory (for example, when using Webpack-dev-server), but they may also be stored in a JSON file.
in the module
HMR is an optional feature that only affects modules that contain HMR code.
For example, by style-loader
appending a patch to a style style.
In order to run the Append patch, style-loader
the HMR interface is implemented, and when it receives the update via HMR, it replaces the old style with the new style.
Similarly, when you implement the HMR interface in a module, you can describe what happens when the module is updated.
In most cases, however, it is not necessary to force the HMR code to be written in each module.
If a module does not have a HMR handler function, the update will bubble.
This means that a simple handler function is able to update the entire module tree.
If a separate module is updated in this module tree, the entire set of dependent modules will be reloaded.
For module.hot
more information about interfaces, see the HMR API page.
in the HMR Runtime
These things are more technical ... If you are not interested in the inside, you can skip to the HMR API page or the HMR guide at any time.
For the runtime of the module system, additional code is sent to parents
and traced to the children
module.
In terms of management, runtime supports two methods check
and apply
.
check
Sends an HTTP request to update the manifest. If the request fails, the update is not available.
If the request succeeds, the chunk to be updated is compared to the currently loaded chunk.
For each loaded chunk, the corresponding update chunk will be downloaded.
When all pending updates chunk complete the download, you are ready to switch to the ready
status.
apply
method to mark all updated modules as invalid.
For each invalid module, you need an update handler in the module, or an update handler in its parent module.
Otherwise, the invalid token bubbles and also invalidates the parent.
Each bubbling continues until the application entry start point is reached, or a module with an update handler function is reached (whichever is first arrived).
If it bubbles from the beginning of the entry, the process fails.
All invalid modules are then processed and deallocated (via the dispose handler function).
The current hash is then updated and all the "accept" handler functions are called.
Runtime switches back to 闲置
status, and everything continues as usual.
Getting Started
In the development process, HMR can be used as an alternative to livereload. Webpack-dev-server support hot
mode, the hot mode tries to update with HMR before attempting to reload the entire page. See the Module Thermal Update guide for more details.
Like many other features, Webpack is powerful because it's customizable. Depending on the specific project requirements, there are a number of ways to configure HMR. However, for most implementations, webpack-dev-server
being able to work well together allows you to quickly get started with HMR.
Webpack-hot Module replacement (hot update)