Detailed analysis of JavaScript modular development

Modularization Development is a very important concept in Programming development. The later maintenance cost of an excellent modular project can be greatly reduced. This article mainly introduces those things about JavaScriptModular development. The article explains the modular development process more intuitively through a short story.

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

##Global

VariablesConflict

Based on his own experience, Xiao A first extracted some commonly used functions and wrote them as

The function is placed in a public file base.js:

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_this Global variables, this will conflict with _ in base.js. Little A thought to himself that underscore.js is a third-party library and it is probably not easy 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.

Dependencies

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 base.js and Functions in 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 modifications:

<script src="tabs.js"></script>
<script src="base.js"></script>
<script src="util.js"></script>

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 util.js from all pages that use tabs.js. quotes to 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?

Modularization

When Xiao 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:

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 all added to the exports object. And 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:

define(function(require, exports, module) {
    var _ = require('base.js'), util = require('util.js');
    var p_tabs = _.$('tabs');
    // .... 其他代码
});

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

Variable name is completely controlled by the developer. If you don’t like _, you can also use base:

define(function(require, exports, module) {
    var base = require('base.js'), util = require('util.js');
    var p_tabs = base.$('tabs');
    // .... 其他代码
});

Once To remove util.js and add ui.js, just modify tabs.js:

define(function(require, exports, module) {
    var base = require('base.js'), ui = require('ui.js');
    var p_tabs = base.$('tabs');
    // .... 其他代码
});

Loader

Due to the lack of native browser support, if we want to use modules To encode in a standardized way, you 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.

The above is the detailed content of Detailed analysis of JavaScript modular development. For more information, please follow other related articles on the PHP Chinese website!