Preface to the 01.

In fact, hot replacement has always been there, I have not seen, why????

In fact, he is in essence convenient debugging, faster debugging, but also special to write code, so have not understood why such a function?

One advantage I can think of is that hot replacement is faster to debug when the project is large because each compile takes longer.

The second is that the refresh causes the path to disappear, or something to be filled in again

Now that I’m going back to the Webpack document, take a good look

02. Front-end relevance

Add a hot:true

    devServer: {
      contentBase: './dist',
      hot: true,
    },
Copy the code

Then you need to add separate code to the code

if (module.hot) {
   module.hot.accept('./print.js', function() {
     console.log('Accepting the updated printMe module!');
     printMe();
   })
 }
Copy the code

Update printMe() when print.js changes.

You can then implement hot updates instead of refreshing the entire page

It’s cool, but wouldn’t it be too much trouble if you had to do this every time you wrote code?

And this is just the simplest way to refer to it; there are other ways to use it in the example.

I will see how they apply it when I study VUe3.0 later.

Principle of 03.

First, in Webpack’s Watch mode, a file in the file system changes, WebPack listens to the file changes, recompiles and packages the module according to the configuration file, and saves the packaged code in memory through a simple JavaScript object.

The second step is the interface interaction between Webpack-dev-server and Webpack. In this step, it’s mainly the interaction between Webpack-Dev-middleware of Dev-server and Webpack. Webpack-dev-middleware calls the API exposed by Webpack to monitor code changes and tells Webpack to pack the code into memory.

The third step is a monitoring of file changes by Webpack-dev-server, which is different from the first step in that it does not monitor code changes for repackaging. . When we are in the configuration file is configured with devServer watchContentBase to true, the Server will listen to these configuration static files in the folder change, change will notify the browser after the live for the application to reload. Notice that this is browser refresh, and HMR are two different things.

The fourth step is also the work of the webpack-dev-server code. This step mainly uses sockJS (webpack-dev-server dependency) to establish a websocket long connection between the browser and the server. This tells the browser about the status of the various stages of the Webpack compilation and packaging, as well as the information that the Server listens for static file changes in step 3. The browser performs different operations based on these socket messages. Of course, the most important information passed by the server is the hash value of the new module, and the subsequent steps use this hash value to perform module hot replacement.

The webpack-dev-server/client cannot request updated code and does not perform hot module operations, handing the work back to Webpack. The job of webpack/hot/dev-server is to decide whether to refresh the browser or hot update the module based on the information passed to it by webpack-dev-server/client and the configuration of dev-server. Of course, if you just refresh the browser, there are no further steps.

HotModuleReplacement runtime is the centre of the client HMR, step on it receives hash value passed to his new module, it through JsonpMainTemplate. Runtime sends an Ajax request to the server end, The server returns a JSON that contains the hash values of all the modules to be updated. Once the updated list is retrieved, the module requests the latest module code again via JSONP. These are steps 7, 8 and 9 in the figure above.

In step 10, the HotModulePlugin will compare the old and new modules and decide whether to update the module. After the decision is made, the dependency relationship between the modules will be checked and the dependency references between the modules will be updated. As a final step, when HMR fails, we fall back to live Reload, which is a browser refresh to get the latest packaging code.

This is actually quite clear, I simply understand as

Sockjs creates a long websocket link between the service and the browser, notifies the browser of the change (JSON) after each change, and then reloads the new JS via JSONP based on json.

That’s it in a nutshell.

04. Summary.

It’s still an optional feature for me right now, extra code, and it can go wrong.

Maybe when the project is big or when the actual test needs to save the state