Explanation of webpack: five methods of require, webpackrequire

Explanation of webpack: five methods of require, webpackrequire

In webpack, you can write the require synchronization syntax in commonjs format, the require callback syntax in AMD format, and a require. ensure and webpack self-defined require. add the ES6 import syntax, so many will not confuse people. In this article, we will sort out the respective features of these require and the scenarios in which they are used.

Commonjs synchronization syntax

The typical commonjs synchronization syntax is as follows:

var a = require('./a');a.show();

In this case, webpack will Package a. js into the file that references it. This is the most common situation, so do not go into details.

Commonjs asynchronous loading

There is A Modules/Async/A specification in commonjs, which defines the require. ensure syntax. Webpack implements code sharding and asynchronously loads the code after sharding during packaging. The usage is as follows:

require.ensure([], function(require){  var list = require('./list');  list.show();}); 

In this case, list. js will be packaged into a separate chunk file, which is about long:

1. fb874860b35831bc96a8. js

Poor readability. I mentioned at the end of the previous article that the way to name it is to pass the third parameter to require. ensure, for example:

require.ensure([], function(require){  var list = require('./list');  list.show();}, 'list'); 

In this way, you can get the name of the file you want:

List. fb874860b35831bc96a8. js

You can also enter a hierarchical name like "question/list", so that webpack will create folders for you according to the hierarchy.

It should be noted that if you reference more than two modules in the require. ensure Function, webpack will package them together, for example:

require.ensure([], function(require){  var list = require('./list');  list.show();  var edit = require('./edit');  edit.display();}, 'list_and_edit'); 

List. js and edit. js will be packaged into a file and named list_and_edit.js. This is measured based on your actual situation. If you do not want to package them together, you can only write two require. ensure files to reference them respectively.

To put it another way, I really don't like this kind of thinking. In the coding stage, I have to make decisions on packaging, obviously violating the separation of duties principle.

Commonjs pre-load lazy execution

In the above usage, we passed an empty array to the first parameter of require. ensure. In fact, the module name can be received here, and its role is to implement pre-loading and lazy execution. The usage is as follows:

require.ensure(['./list'], function(require){  var list = require('./list');  list.show();}); 

To require. ['. /list']. When the command is executed here, list. js will be downloaded by the browser, but the list will not be executed. the code in the js module, which is said on the webpack official website, will not be evaluate. When evaluate is implemented, the following var list = require ('./list') is returned. This is called lazy execution.

Multiple modules written in the function will be packaged together, which is no different from the above. In addition, the modules written in the array will be packaged with them, whether you manually execute them or not.

This writing method is also a bit awkward, such as the combination of commonjs and AMD, and it is not elegant enough to write a module name twice. Therefore, webpack defines a method to implement pre-loading.

Webpack built-in require. include

Require. include is provided by webpack itself, and there is no standard for backend, so it is a small role. It can implement the preload function, instead of writing modules in an array. The usage is as follows:

Require. ensure ([], function (require) {require. include ('./list'); // load and not execute here });

According to the webpack official documentation, require. include can also extract the public part of the sub-module to the parent module. For example, both child1 and child2 reference list. if the js module is included in the parent. js, the sub-module will be deleted, which is equivalent to being upgraded to the parent module. (Here, the so-called parent-child relationship is a guiding relationship)

This method is also officially used, and it seems to be a chicken ribs, which is of little use. Because I found that the return value of require. include is undefined, that is, if you want to use a module, the position is as follows:

Require. ensure ([], function (require) {require. include ('. /preview'); // load let p = require ('. /preview'); // execute p. getUrl (); // use}, 'pre ');

AMD asynchronous loading

Webpack supports both commonjs specifications and AMD specifications, which means that AMD's classic syntax can be used normally, for example:

require(['./list'], function(list){  list.show();}); 

Of course, in this case, list. js is separately packaged into a file. Similar to the above, if you write multiple modules here, these modules will be packaged into a file, such:

require(['./list', './edit'], function(list, edit){  list.show();  edit.display();}); 

List. js and edit. js will be packaged together. The difference is that AMD cannot pass in the third parameter as the file name, so it cannot get a good-looking file.

ES6 import

This year, ES6 is not used to say hello to people. Therefore, in our code, there will be another syntax for introducing modules, that is, import. Import will be converted to the commonjs format or AMD format, so do not regard it as a new module reference method. By default, babel converts the ES6 module to the commonjs specification, and you don't have to bother turning it into AMD.

Therefore, the following statement is equivalent:

Import list from './list'; // equivalent to var list = require ('./list ');

However, you only need to select one of the two writing methods to avoid both of them in the Code. Otherwise, obfuscation may occur.

Summary

The above describes the usage of require again. After understanding the differences between their respective usage, we can make a selection in the project. I think the best choice is to move closer to commonjs. If you want to try ES6, use import instead of the commonjs synchronization syntax.

Therefore, keep the following two styles in the Code:

// The synchronization code that can be packaged together, using the import syntax import list from '. /list'; // code that needs to be independently packaged and asynchronously loaded using require. ensurerequire. ensure ([], function (require) {var list = require ('. /list ');});

Obviously, you still need to make decisions on the packaging results when writing code, which is why I don't like webpack. As good as gulp, encoding is encoding, compilation is compilation, and separation. However, this is the feature of webpack packaging with modules as the core. As long as a contract is made within the team, it will not be a mess.

The above is all the content of this article. I hope it will be helpful for your learning and support for helping customers.