Webpack Learning-Module Hot swap (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.

in the application

The following steps allow you to displace (swap in and out) modules in your application:

1. Application code requires HMR runtime to check for updates.
2. HMR Runtime (asynchronously) downloads the update and then notifies the application code.
3. Application code requires HMR Runtime app update.
4. 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:

1. Updated manifest (JSON)
2. 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 to be 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.

in the HMR Runtime

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 .

  checkSends 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.

  applymethod 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.

Webpack Learning-Module Hot swap (replacement)