This article introduces you to Angular development practice (2): HRM operating mechanism. Interested friends can take a look at

Introduction

is enabled in the angular-start project The Hot Module Replacement (HMR - Hot Module Replacement) function has been installed. For how to enable HRM in angular-cli, please view the HRM configuration

So what is HMR?

HMR is a function provided by webpack, angular-cli uses it, it will replace and add during the running process of the application Or remove the module without reloading the entire page. Mainly through the following methods, to significantly speed up development:

• Preserve application state that is lost when the page is completely reloaded

• Update only changes to save valuable development time

• Adjust styles faster - almost equivalent to changing styles in the browser debugger

How does this all work?

Let’s take a look at the specific effects first:

1. Start the angular-start project. In the console you can see that HRM has been enabled. Message:

##2. Then you can see through the browser console that all resources are requested for the first load:

#3. At this time, modify a code and save it. The browser will automatically display the modified effect without refreshing. Look at the browser console and only request Newly modified js:

Let’s look at it from some different angles to understand how

HMR works…

In the application

You can swap (

swap in and out) the module in the application through the following steps:

• Application code asks HMR runtime to check for updates

• HMR runtime (asynchronously) downloads updates and then notifies application code

• App Program code requires HMR runtime to apply updates

• HMR runtime (asynchronous) to apply updates

In the compiler

In addition to ordinary For resources, the compiler (

compiler) needs to issue update to allow updating the previous version to the new version. update consists of two parts:

• The updated

  manifest (JSON)

• a or multiple updated

  chunk (JavaScript)

##manifest

including the new compiled hash and all pending Update chunk directory. Each update chunk contains code corresponding to all updated modules for this chunk (or a flag to indicate that this module is to be removed). The compiler ensures that the module

ID

and chunk ID remain consistent between these builds. These ID are usually stored in memory (for example, when using webpack-dev-server), but it is also possible to store them in a JSON file. In modules

HMR

is an optional feature and will only affect modules containing HMR code. For example, add a patch to the style style through style-loader. In order to run additional patches, style-loader implements the HMR interface; when it receives an update via HMR, it replaces the old style with the new one. Similarly, when implementing the

HMR

interface in a module, you can describe what happens when the module is updated. In most cases, however, there is no need to force writing HMR code in every module. If a module does not have a HMR handler, updates will bubble up. This means that a simple handler function can update the entire module tree(complete module tree). If a single module in this module tree is updated, the entire set of dependent modules will be reloaded. For details on the module.hot interface, please check out the HMR API page.

In HMR Runtime

For the module system's

runtime

, additional code is sent to parents and children for tracking module. In terms of management, runtime supports two methods check and apply.

check

Send a HTTP request to update the manifest. If the request fails, no updates are available. If the request is successful, the chunk to be updated will be compared with the currently loaded chunk. For each loaded chunk, the corresponding chunk to be updated will be downloaded. When all pending updates chunk have been downloaded, they will be ready to switch to the ready state. <p><code>applyThe method marks all updated modules as invalid. For each invalid module, there needs to be an update handler in the module or in its parent modules. Otherwise, the invalid tag bubbles up and invalidates the parent as well. Each bubbling continues until it reaches the application entry point, or the module with the update handler, whichever comes first. If it starts bubbling from the entry point, the process fails.

Afterwards, all invalid modules are processed (via the dispose handler function) and unloaded. Then update the current hash and call all accept processing functions. runtimeSwitch back to idle state and everything continues as usual.

Reference article

http://www.css88.com/doc/webp...

Related recommendations:

Angular Development Practice (1): Environment Preparation and Framework Construction

The above is the detailed content of Angular development practice (2): HRM operating mechanism. For more information, please follow other related articles on the PHP Chinese website!