In webpack, you can write commonjs format require synchronization syntax, AMD format require callback syntax, and one, as well as webpack itself defined, plus ES6 import syntax, wouldn't so much mess up people? This article will sort out the characteristics of these requirements and the scenarios they are used in.
commonjs synchronization syntax
The classic commonjs synchronization syntax is as follows:
var a = require('./a');
();
At this time webpack will package it into the file that references it. This is the most common situation and needs no further description.
commonjs asynchronous loading
There is a Modules/Async/A specification in commonjs, which defines syntax. webpack implements it, and its function is to shard code during packaging and asynchronously load the sharded code. The usage is as follows:
([], function(require){
var list = require('./list');
();
});
At this time, it will be packaged into a separate chunk file, probably like this:
1.
Poor readability. I also mentioned at the end of the previous article that the way to name it is to pass a third parameter, such as:
([], function(require){
var list = require('./list');
();
}, 'list');
This will get the file name you want:
list.
You can also pass in a hierarchical name like "question/list", so webpack will create folders for you according to the hierarchy.
It should be noted that if you reference more than two modules in your function, webpack will package them together, for example:
([], function(require){
var list = require('./list');
();
var edit = require('./edit');
();
}, 'list_and_edit');
and will be packaged into a file and named list_and_edit.js. This needs to be measured based on your actual situation. If you do not want to package it together, you can only write two files to refer to them separately.
To put it more, I actually don’t like this kind of thinking. However, I have to make decisions on packaged things during the coding stage, which obviously violates the principle of separation of responsibilities.
commonjs preload lazy execution
In the above usage, the first parameter we gave is an empty array. In fact, the module name can be received here, and the function is to implement preloading lazy execution. The usage is as follows:
(['./list'], function(require){
var list = require('./list');
();
});
The first parameter given is passed ['./list']. When it is executed here, it will be downloaded by the browser, but the code in the module will not be executed, which is what the webpack official website says, and will not evaluate it. When you really evaluate it, it is the next sentence var list = require('./list'); this is what is called lazy execution.
Multiple modules written in functions will be packaged together, which is no different from the above. In addition, modules written in arrays will also be packaged with them, regardless of whether you have manually executed them or not.
This way of writing is also a bit awkward, such as a combination of commonjs and AMD, and the name of a module needs to be written twice, which is really not elegant enough. So webpack defines a method itself to implement preloading.
Webpack comes with
It is provided by webpack itself and there are no specifications to do the backend, so it is a small role. It can implement the above preload function without writing modules in an array. The usage is as follows:
([], function(require){
('./list');// Only loading here will not be executed
});
According to the webpack official documentation, another function is to extract the common parts of the submodule into the parent module. For example, children1 and children2 refer to this module. If they are included in the parent, the submodule will be deleted, which is equivalent to being promoted to the parent module. (The so-called father-son relationship here refers to the reference relationship)
This method has also been mentioned in the official statement, and it seems to be a useless thing and is not very useful. Because the return value I found is undefined, that is, if you want to use modules, the pose is like this:
([], function(require){
('./preview'); //load let p = require('./preview'); //implement (); //use}, 'pre');
AMD asynchronous loading
webpack supports both commonjs specifications and AMD specifications, which means that AMD's classic syntax can be used normally, such as:
require(['./list'], function(list){
();
});
Of course, writing like this is also packaged into a file separately. Similar to the above, if you write multiple modules here, then these modules will be packaged into a file, such as:
require(['./list', './edit'], function(list, edit){
();
();
});
and will be packed together. The difference is that AMD's method cannot pass in the third parameter as the file name, so it cannot get a very good-looking file.
ES6 import
These days, I feel embarrassed to say hello to others without using ES6. So in our code, there will be another module that introduces syntax, that is, import. Import will be converted to commonjs format or AMD format, so don't think it is a new way of referencing modules. Babel will convert ES6 modules into commonjs specifications by default, and you don’t have to struggle to convert it to AMD.
So the following writing method is equivalent:
import list from './list';
//Equivalent to
var list = require('./list');
However, you only need to choose one of these two ways to avoid using two at the same time in the code, otherwise it will cause confusion.
Summarize
The above has sorted out the usage of require. After understanding the differences between their usages, we can make choices in the project. I think the best choice is to move closer to commonjs. If you want to try ES6, use import instead of commonjs synchronization syntax.
Therefore, it is good to maintain the following two styles in the code:
//Synchronous code that can be packaged together, using import syntax
import list from './list';
//Code that needs independent packaging and asynchronous loading, use
([], function(require){
var list = require('./list');
});
Obviously, when you write code, you still need to make decisions on the packaging results, which is why I don’t like webpack. How good is gulp? Coding is encoding, compilation is compilation, separate. But this is the characteristic of webpack's module-centric packaging method. It depends on one's personality. As long as an agreement 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 to everyone's study and I hope everyone will support me more.