Understand the modular development of Javascript_javascript skills

Little A is a front-end engineer of a startup team and is responsible for writing the project's Javascript program.

Global variable conflict

Based on his own experience, Xiao A first extracted some commonly used functions, wrote them as functions and put them in a public file base.js:

Copy code The code is as follows:

var _ = {
$: function(id) { return document.getElementById(id); },
GetCookie: function(key) { ... },
setCookie: function(key, value) { ... }
};

Little A puts these functions in the _ object to prevent conflicts caused by too many global variables. He told other members of the team that if anyone wanted to use these functions, just import base.js.

Little C is a colleague of Little A. He reported to Little A: His page has introduced a class library called underscore.js, and this class library will also occupy the _ global variable, so it will follow _ in base.js conflicts. Little A thought to himself that underscore.js is a third-party library and it is probably difficult to change, but base.js has been deployed on many pages and it is impossible to change it. In the end, Little A had no choice but to change the global variables occupied by underscore.js.

At this time, Little A discovered that placing all functions in a name space can reduce the probability of global variable conflicts, but it does not solve the problem of global variable conflicts.

Dependency

With the development of business, Xiao A has written a series of function libraries and UI components, such as the tab switching component tabs.js. This component needs to call functions in base.js and util.js.

One day, new colleagues Xiao D and Xiao A reported that they had referenced tabs.js in the page, but the function was not normal. Little A discovered the problem at first glance. It turned out that Little D did not know that tabs.js depends on base.js and util.js, and he did not add references to these two files. So, he immediately made changes:

Copy code The code is as follows:

However, the function was still abnormal. At this time, Little A taught Little D: "It is said to be dependent, so the dependent party must be placed before the relying party." It turns out that Xiao D put base.js and util.js after tabs.js.

Little A thought to himself that as the author, he naturally knows the dependencies of components, but it is difficult for others to tell, especially newcomers.

After some time, Xiao A added a function to the tab switching component. In order to realize this function, tabs.js also needs to call the function in ui.js. At this time, Little A discovered a serious problem. He needed to add references to ui.js on all pages that called tabs.js! ! !

After some time, Xiao A optimized tabs.js. This component no longer depends on util.js, so he removed the references to util.js in all pages that use tabs.js. Improve performance. His modification caused a big problem. The test team MM told him that some pages were abnormal. Little A took a look and suddenly realized that other functions of some pages used functions in util.js. He removed the reference to this file and an error occurred. To ensure normal functionality, he restored the code.

Little A thought again, is there a way to modify dependencies without modifying the pages one by one, without affecting other functions?

Modular

When Little A was browsing the Internet, he accidentally discovered a novel modular coding method that could solve all the problems he had encountered before.

In modular programming, each file is a module. Each module is created by a function called define. For example, after transforming base.js into a module, the code will become like this:

Copy code The code is as follows:

define(function(require, exports, module) {
exports.$ = function(id) { return document.getElementById(id); };
exports.getCookie = function(key) { ... };
exports.setCookie = function(key, value) { ... };
});

The interfaces provided by base.js are added to the exports object. Exports is a local variable, and the code of the entire module does not occupy half of the global variable.

How to call the interface provided by a certain module? Take tabs.js as an example, it depends on base.js and util.js:

Copy code The code is as follows:

define(function(require, exports, module) {
var _ = require('base.js'), util = require('util.js');
var div_tabs = _.$('tabs');
// .... Other codes
});

A module can obtain the interfaces of other modules through the local function require. At this time, the variables _ and util are both local variables, and the variable names are completely controlled by the developer. If you don’t like _, you can also use base:

Copy code The code is as follows:

define(function(require, exports, module) {
var base = require('base.js'), util = require('util.js');
var div_tabs = base.$('tabs');
// .... Other codes
});

Once you want to remove util.js and add ui.js, just modify tabs.js:

Copy code The code is as follows:

define(function(require, exports, module) {
var base = require('base.js'), ui = require('ui.js');
var div_tabs = base.$('tabs');
// .... Other codes
});

Loader

Due to the lack of native browser support, if we want to code in a modular manner, we must use something called a loader.

There are currently many implementations of loaders, such as require.js and seajs. The JRaiser class library also has its own loader.