Discussion on front-end modularization

❝

Frontier: Those who have played qiankun children’s shoes all know that if they want to ensure that the parent application of Qiankun can successfully load its child application. We need to “wrap” the child application, which can be seen in the official documentation by positioning the output mode of WebPack as UMD. What, you might wonder, is this UMD?

❞

1. UMD

❝

UMD is called the Common Module Definition specification, which is also a modular definition evolved from front-end modularity. It is a cross-platform solution to module definition. In other words, UMD can make your code compatible with modules written based on a variety of other modular specifications. It can unify the specification of browser-side and non-browser-side modular solutions. It has strong versatility. But in essence, it does not have its own “specification”, it is actually a collection, CommonJs, AMD and other specifications together, can simultaneously support import, require and script direct reference, simple understanding can be seen below 👇

❞

1.1 Application Scenarios

Suppose you now have a scenario: You need to develop a library, a util method, and at the same time you want this code to be usable both in the NodeJS environment and in the browser, so we use umD output mode, just add libraryTarget to webPack output: ‘UMD’ is a good way to solve cross-platform and cross-environment problems. If you are interested, you can check out kdutil, which is packaged in UMD mode

1.2 Why does Qiankun need to output sub-applications as UMD

❝

In the Qiankun architecture, the umD output format of Webpack was adopted to enable the parent application to bind window to a Proxy object through Eval when executing js resources of the child application, so as to prevent global variables from being polluted. In this way, window-related operations of scripts can be hijacked to achieve script isolation between sub-applications.

❞

1.3 Operating Mechanism 🚗

❝

Use webPack to configure libraryTarget: umD to configure how to expose library. Expose your library in a way that all module definitions can run. This is often used in plug-in development scenarios. In addition to UMD, common configurations include var, this, window, global, CommonJS, CommonJs2, AMD, AMD-require, etc. Umd compatibility is best

❞

// webpack.config.js
module.exports = {
 output: {
    filename: `kdutil.min.js`,
    path: path.resolve(rootPath, 'dist'),
 library: `kdutil`,  libraryTarget: "umd"  },  }   // index.js export default {  name: 'hello 🌲 sauce'.}; Copy the code

• Check whether CommonJS2 is supported (exports exists and module exists). If yes, CommonJS2 is used.
• Then check whether AMD is supported (define exists, because AMD specification defines modules by define). If AMD exists, use AMD mode to load modules. Let’s look at the following webpack output result
• Second, whether the CommonJS specification is supported or not (exports exist), if it does, it uses CommonJS mode to load modules.
• If neither exists, the module is exposed globally (window or global);

We tried to import kdutil directly as a

 <script src=".. /dist/kdutil.min.js"></script>
 <script type="text/javascript">
  console.log(kdutil);
</script>
Copy the code

❝

👨🎓 Ahxuan student: How to add a layer of default, then use variables like kdutil.default, is there a way to make it simpler?

❞

A: Global variables exported with export default will have a default attribute, which can be resolved by adding a configuration to the webpack.out output: libraryExport: “default”

❝

👨🎓 : CommonJS is a module specification for Node.js.

❞

A: Module. exports is the parent of exports, and module.exports is the adopted child of exports. The CommonJS2 specification specifies module. Exports

We use WebPack to package the two specifications separately to make a clear comparison

Library is used for exports. Library is used for exports. Library is used for exports

🌲

• Webpack output configuration details
• UMD (Universal Module Definition)

2. Front-end modularization

❝

👨🎓 Ah stay student: that you say umD is CommonJS, AMD combination, that CommonJS, CMD, AMD these several have what distinction respectively?

❞

Answer: front-end modularity means, through the front-end code according to certain rules decoupling encapsulated into several files (module), and exposed a specific interface or method, and then according to the specific situation in the project development evolution and reasonable, the method of combination of nature helps to promote the efficiency of development, improve the reusability of the code, convenient dependency management.

2.1 Evolution of front-end modularization

Review the development of front-end modularization, from simple function encapsulation and object encapsulation in the early days, to simple modular use of instant function expression (IIFE), script tags loaded according to the order of JS dependent execution, and then to form modular specification evolution, as shown in the figure below

2.2 Distinction between modular specifications

• CommonJS: Nodejs uses the CommonJS (also known as CJS) specification, but because Nodejs loads modules synchronously. The loading of a module must be complete (synchronous loading) before the following operations can be performed. We know that the server loading module files are generally put in the server’s own hard disk, fast loading. Used via exports or modules.exports, require imports

• AMD: async module definition, async module definition, async module definition, async module definition, async module definition, async module definition, async module definition, async module definition, async module definition. There is an AMD specification that allows browser-side modules to be loaded asynchronously, using the define method to define the module (all statements that depend on the module are defined in a callback function that will not run until the module is loaded), relying on RequireJS

• CMD: the same as AMD, both through asynchronous loading, the difference is that AMD is early execution, while CMD is delayed execution, and CMD advocates relying on nearby loading, AMD advocates relying on seaJS

• ES6 modular: Since later out of the ES6 modular, AMD and CMD basic need not, but with ES6 built-in modular, but some browsers do not support ES6 syntax, then need to use Babel to “translate”, for Babel translation can see the tree before Babel stupid read not understand, You can use the export default command to specify the default output for the module and import it with import

	Runtime environment	Loading way	Relying on third-party libraries	Whether Babel compilation is required
CommonJS	The server	Synchronous loading	Don’t need	no
AMD	The browser	Asynchronous loading	requireJs	no
CMD	The browser	Asynchronous load (load on demand)	seajs	no
UMD	Browser + Server	Asynchronous loading	Don’t need	no
ES6 Module (ESM)	Browser + Server	Synchronous loading	Don’t need	is

🌲

• Front-end modular development solutions in detail
• Jade bo: AMD and CMD difference what?

2.3 Differences between ES6 Module and CommonJs

❝

👨 : The usage of CommonJs and ES6 Module is easily confused, what is the difference between the two?

❞

A: Yes, look at the table below

	CommonJS	ES6 Module
Output way	The output is a copy of the value	The output is a reference to the value, which the module can change in real time
run	Run time loading	Compile-time output interface
Whether treeshake is supported	Does not support	Support (because static analysis is supported)

In terms of output, the former is a copy value and the latter is a reference value

When the lib.js module is loaded, its internal changes do not affect the output lib.counter, because essentially lib.counter is a primitive value that will be cached. The latter ES6 module operates differently from CommonJS. When a module is statically analyzed by the JS engine, a read-only reference is generated when the module load command import is encountered. When the script is actually executed, it will be evaluated in the loaded module based on the read-only reference and will not be cached

In essence, the resolution of module dependencies is dynamic (module dependencies are established at the time the code is run), while the latter is static (module dependencies are established at the time the code is compiled)

🌲

• Module. exports and exports, export and export default
• ES Module 1: Disable export default Object

2.4 Can import replace require for dynamic loading?

Let’s take a look at the code above, if it’s wrong. As we saw in the previous section, the import is processed by the JS engine in the compilation phase. This phase will not analyze or execute the if statement, so it is meaningless to put the import statement in the if statement, which will report syntax errors, that is, import and export commands can only be at the top of the module.

So if I want to load a dynamic module, require I can write it like this. Which module is loaded by require will not be known until it is run

❝

Ah Ling: Is there no other way to dynamically load modules other than require?

❞

A: Yes, the ES2020 proposal introduces the import() function, which can be used to support dynamic loading of modules. The difference between the two is that the former require is synchronous loading, while the latter is asynchronous loading. Please refer to the usage document 🔗 for details

2.5 How Do I Use the ES6 Module to Load nodes

❝

Ahbin: Shujiang, if I want to use es6 module to load in node environment, is that ok?

❞

A: Yes, but mixing is not recommended. Node has ES6 Module support on by default since v13.2. If you want to use es6 module loading in the Node environment, you need the.mjs suffix filename. If Node.js encounters an.mjs file, it will be treated as an ES6 module. If you don’t want to change the suffix to.mjs, you can specify the type field as module in your project’s package.json file. However, this means that js in this directory can only interpret ES6 modules. If you want to use CommonJS modules, you need to change the suffix of CommonJS script to.cjs.

❝

To put it simply:.mjs files are always loaded as ES6 modules,.cjs files are always loaded as CommonJS modules, and.js files are loaded depending on the type field in package.json

❞

🌲 sauce previous articles:

• Construction of front-end Knowledge System of Tree Jam (PART 1)
• Construction of front-end Knowledge System of Tree Jam (Part 2)
• Talk about daily collaboration tools for front-end development
• Babel configuration is stupid
• How to better manage the Api
• The interviewer asks you about Node
• Front-end engineering stuff
• Did you learn BFF and Serverless
• Front-end operations and deployment

Please drink a cup 🍵 remember three even oh ~

1. Remember to give 🌲 sauce a thumbs up after reading oh, there is 👍 motivation

2. Pay attention to the interesting things at the front of the public account, and chat with you about the interesting things at the front

3. Github frontendThings thanks to Star✨