I previously in the "Front end of the environment from the beginning to give up" this article spit, Webpack can write COMMONJS format require synchronization syntax, can write the AMD format require callback syntax, There is also a require.ensure, and webpack own definition of require.include, plus ES6 import grammar, so many will not confuse people. This article will be to comb the characteristics of these require, and in what scenarios are used.
COMMONJS synchronization Syntax
The classic COMMONJS synchronization syntax is as follows:
var a = require ('./a '); A.show ();
At this point Webpack will package the a.js into the file that references it. This is the most common situation, do not need to repeat.
Commonjs Asynchronous loading
There is a MODULES/ASYNC/A specification in Commonjs that defines the require.ensure syntax. Webpack implements it, which allows code fragmentation at the time of packaging, and asynchronously loading the Shard code. Use the following:
function (Require) { var list = require ('./list '); List.show ();});
At this point the list.js will be packaged as a separate chunk file, presumably long:
1.fb874860b35831bc96a8.js
Poor readability. I also mentioned at the end of the previous article that the way to name it is to pass a third argument to require.ensure, such as:
function (Require) { var list = require ('./list '); ' List ');
This will give you the file name you want:
List.fb874860b35831bc96a8.js
You can also pass in a hierarchical name like "Question/list" so that Webpack will create folders for you at the level.
It is important to note that if you refer to more than two modules in the Require.ensure function, Webpack will pack them together, for example:
function (Require) { var list = require ('./list '); List.show (); var edit = require ('./edit '); ' List_and_edit ');
List.js and Edit.js will be packaged as a file and named List_and_edit.js. This needs to be measured according to your actual situation, if you do not want to pack together, can only write two require.ensure to refer to these two files respectively.
To say a word, this kind of thinking in fact I am very dislike, in the coding phase but to packaging things to make decisions, obviously against the separation of duties principle.
Commonjs Pre-loading lazy execution
In the above usage, we send an empty array to the first argument of require.ensure, in fact, it is possible to receive the module name, the function is to implement lazy execution of preload. Use the following:
function (Require) { var list = require ('./list '); List.show ();});
To require.ensure the first parameter passed the ['./list '], the implementation of this time list.js will be downloaded by the browser, but will not execute the List.js module code, that is, Webpack website said, will not be evaluate. The real evaluate is at the back of this sentence var list = require ('./list '); this is called lazy execution.
Multiple modules written in the function are packaged together, which is no different from the above. In addition, the modules written in the array will be packaged with them, whether or not you have done it manually.
This kind of writing is also a bit awkward, like COMMONJS and AMD's combination, and a module name to write two times, is really not elegant. So Webpack itself defines a method that can be preloaded.
Webpack's Own Require.include
Require.include is webpack to provide, and there is no standard to do backstage, so is a small role. It can be implemented with the preload function instead of writing the module in the array, using the following:
function (Require) { require.include ('./list '); only load does not execute here });
According to the Webpack official website document Introduction, Require.include also has a role to be able to handle the public part of the module, extracted into the parent module, such as Child1 and child2 all reference list.js This module, then if the parent include List.js, then the sub-module will be deleted, equivalent to ascend to the The parent module. (The so-called parent-child relationship refers to a reference relationship)
This method of official is also a stroke, it seems to be a chicken thing, the use is not good. Because I found that the return value of require.include is undefined, that is, if you want to use a module, the posture is this:
function (Require) { require.include (// load / / Execute // Use }, ' pre ');
AMD Asynchronous load
Webpack supports both the COMMONJS specification and the AMD specification, which means that AMD's classic syntax can be used normally, such as:
function (list) { list.show ();});
Of course, List.js is also packaged separately as a file. Similar to the above, if you write more than one module here, then these modules will be packaged as a file, such as:
function (list, edit) { list.show (); Edit.display ();});
List.js and Edit.js will be packaged together. The difference is that the AMD way cannot pass in the third parameter when the file name is not getting very nice files.
ES6 Import
These days do not have to ES6 are embarrassed to greet people. So in our code, one more module introduces the syntax, which is import. Import will be converted to COMMONJS format or AMD format, so don't think of it as a new way of referencing a module. Babel the ES6 module into the COMMONJS specification by default, you don't have to bother turning it into AMD.
So the following notation is equivalent:
Import list from './list '; // equivalent to var list = require ('./list ');
However, these two types of writing only need to choose one, avoid using both in the code, otherwise it will cause confusion.
Summarize
After require the usage, we can make a selection in the project after we understand the difference of their usage. I think the best choice is to Commonjs direction, want to try to ES6 words with import instead of COMMONJS synchronization grammar.
So it's good to keep the following two styles in your code:
// a synchronized code that can be packaged together, using import syntax to import the list from './list '; // code that needs to be individually packaged, loaded asynchronously, using the Require.ensure function (Require) { var list = require ('./list ');});
Obviously, you still need to make decisions about packaging results when you write code, which is why I don't like webpack. Gulp that much good, coding is coding, compiling is compiled, separated. But this is the Webpack module as the core of the packaging of the characteristics of the people, as long as the team to make a pact, will not play a mess.
If you are new to the COMMONJS and AMD's characteristics are not very clear, recommend to see what I wrote earlier this: JS Modular process
Webpack: Five ways to use require