Shulou(Shulou.com)06/02 Report--

This article introduces to you what are the two problems to be solved by front-end modularization, the content is very detailed, interested friends can use it for reference, I hope it can be helpful to you.

Preface

Front-end modularization, mainly to solve two problems "namespace conflict", "file dependency management".

Pit _ Namespace conflict

How did the code I tested conflict with everyone after merging?

The variables or functions of the page script override those of the public script.

Pit _ file dependency management

When the packages that need to be introduced into the project are brought in, how can you still report the lack of packages?

Manual management of dependencies, one day to replace a plug-in, to go deep into the code to modify

As shown in the following figure, the code is loaded and the dependency is complex. In F.js, you can't tell whether a variable comes from C.js or E.js.

Load the same module twice. For example, JQ was introduced twice.

Other pits.

In order to achieve script reuse, a large common public file is introduced into each page, some of which are used only by individual pages.

The function group functions of one function, placed together with the function group of another function, are separated by comments.

At present, the solution is: modularization

Namespace: the namespaces of each module are independent. The variable x of module A does not override the variable x of module B.

Module dependency: managed by module management tools such as webpack/requireJS/browserify.

The basic principle of modularization to solve namespace conflicts

Global variables bear the brunt of JavaScript's flaw. This makes you think twice and think twice every time you want to name a variable, lest a colleague's code conflict with you. Here are some precautions

I. use of namespaces

The code is as follows:

/ / define var module = {name: 'rouwan', sayName:function () {console.log (this.name)}} / / use var a = module.name; console.log (a)

Summary: modifying name directly does not affect module.name and protects namespaces to some extent. There are two disadvantages. First, the properties and methods of module can still be modified externally. Second, namespaces sometimes grow beyond your imagination. Suitable for some small packages, such as some configurations.

Execute the function + closure immediately (the basic method of implementing the module)

Immediate functions can create scopes, and closures can form private variables and functions

/ / create var module = (function () {var privateName = 'inner' / / Private variable var privateFunc = function () {/ / Private function console.log ('private function')} return {name: 'rouwan' / / Public attribute sayName:function () {/ / Public function console.log (this.name)}) () / / use module.sayName () / / 'rouwan'

Summary: this is a commonly used way of module definition at present, which can distinguish between private members and public members. Public variables and methods can be modified directly through module.name as before. Private variables and methods cannot be accessed unless you are given a public method to modify private members.

Third, on the basis of the above, introduce other modules

/ / define var module1 = (function (mod) {var privateName = 'inner1' Var privateFunc = function () {console.log ('private function 1')} return {name:' rouwan1', sayName: function () {console.log (this.name)} AnotherName:mod.name, / / Public parameter sayAnotherName:mod.sayName on another module / / Public method on another module}}) (anotherModule) / / introduced another module / / uses module1.sayOtherName ()

Summary: another module can be introduced into one module.

4. Other ways

In the past, magnification mode is used to manage large modules and split files. Now that modular tools such as webpack are perfect, they have lagged behind a bit. I won't introduce you.

Bid farewell to the era of slash-and-burn cultivation modular construction tools (solving dependency management)

I understand that the js module starts by executing the function immediately. But when it comes to the actual use of build tools, it is found that the modular approach adopted by the industry is not a cluster formed by immediate functions + closures.

Instead, modular implementations such as AMD/CMD/CommonJS/ES6 modules are used.

The reasons for this may be these, first, the performance problems of closures. Second, when the number of modules increases, it is necessary to solve the problem of dependency management between modules.

With regard to dependency management, several uncomfortable areas have been encountered in the project:

There is only one picture, there is no need to say much.

Jq has been introduced twice in HTML, resulting in a footer error.

There is a common script that contains more than N common modules. Some pages obviously use only one module and must be loaded all over again.

Therefore, modular management tools must be used!

Several concepts

Package management tools: install, uninstall, update, view, search, publish packages. For example, you need to install a jq, etc., through npm to install. There is dependency management in npm. If jq or express is upgraded, the original code cannot be used. The one who helps you solve this problem is npm.

Modular build tools: webpack/requireJS/seaJS, etc., are build tools (loaders) used to organize front-end modules. Load on demand by using the syntax of the Modularization Specification (AMD/CMD/CommonJS/es6). Take Chestnut, for example, if one day you don't have to maintain a long public script file, thank it.

Modular specifications: AMD/CMD/CommonJS/es6 modules and other specifications that govern how to organize your code. Generally, the code written in this way is not recognized by the browser and needs to be packaged and compiled into a file that the browser can recognize with a modular build tool.

From my table, you can see my recommended match-npm + webpack + es6 module.

The reasons are as follows:

Comparison of npm and bower:

It turns out that the advantage of using bower is that it is suitable for front-end module management, while npm is regarded as only suitable for back-end management. But with the popularity of webpack, there is no doubt that npm has won. Npm+webpack, can achieve good front-end module management.

Webpack and requireJS comparison:

Comparison of several modular specifications:

So it's you! Npm + webpack + es6 module.

On the front-end modularization to solve the two problems are shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.