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

This article mainly explains "what are the characteristics of the well-organized structure of JavaScript code?" interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what are the characteristics of the well-organized structure of JavaScript code.

As JavaScript projects grow, they tend to become difficult to manage if you don't handle them carefully. We find ourselves in some of the problems we often run into: when creating new pages, we find it difficult to reuse or test previously written code.

When we study these problems more deeply, we find that the root cause is caused by ineffective dependency management. For example, script A depends on script B, which in turn depends on script C, and when C is not introduced correctly, the entire dependency chain does not work properly.

To solve this problem, we have adopted the pattern of asynchronous module definition (AMD) and introduced require.js into our technology stack. After further exploration of AMD, we have basically determined that a well-organized JavaScript generally presents the following five characteristics:

Always declare that our dependencies add shim (gasket) definitions and calls to the third-party code base should be separate dependencies should be asynchronously loaded modules should not rely on global variables

Let's discuss it in detail.

Always declare our dependence

One of the most common problems we encounter is that we often ignore dependencies that are determined to be loaded. For example, if we create a jQuery plug-in, it is generally considered unnecessary to declare a dependency on jQuery because it is loaded by default on most pages. While this seems to apply to most web pages, it becomes a problem when we try to unit test or load on an entirely new page.

By declaring our dependencies all the time, we eliminate 90% of the problems in JavaScript. Reusable code has become more reliable, and a fourfold increase in the number of unit tests is also a factor.

Add shim (gasket) to the third-party code base

An interesting problem you often encounter when managing JavaScript dependencies is that older third-party libraries may not work with your dependency management system. For example, you internally use a cool plug-in for jQuery, but it knows nothing about require.js. This will be a problem, because of the first feature, let's add a reference to the plug-in.

The solution is to make a gasket for the plug-in by relying on the management tool. In require.js, this can be easily done through configuration:

Var require = {

1.

"shim": {

two。

"lib/cool-plugin": {

3.

"deps": ["lib/jquery"]

4.

}

5.

}

6.

}

With this simple configuration, every script that loads lib/cool-plugin.js loads jQuery automatically. Will help to satisfy all correlations.

The end result is that the code is easier to test and reuse because you always have a require () to invoke the required functionality.

Definition and invocation should be separated

This is a common problem that limits the reusability and testability of JavaScript code. The problem is that a single file defines a class / function and calls it. Consider the following code:

# # js/User.js

1.

Define (functino (require) {

two。

Var User = function (name, greeter) {

3.

This.name = name

4.

This.greeter = greeter

5.

}

6.

User.prototype.sayHello = function () {

7.

This.greeter ("Hello," + this.name)

8.

}

9.

Var user = new User ('Alice', window.alert)

10.

User.sayHello ()

11.

})

In this example, a single file defines the User class and calls it. It will be difficult to reuse this code, because alert will appear as soon as the script is loaded. Again, greeter is very difficult to test.

The solution is to maintain the separation of definition and implementation. This helps ensure reusability and testability:

# # js/User.js

1.

Define (functino (require) {

two。

Var User = function (name, greeter) {

3.

This.name = name

4.

This.greeter = greeter

5.

}

6.

User.prototype.sayHello = function () {

7.

This.greeter ("Hello," + this.name)

8.

}

9.

Return User

10.

})

11.

# # js/my-page.js

twelve。

Define (functino (require) {

13.

Var User = require ('js/User')

14.

Var user = new User ('Alice', window.alert)

15.

User.sayHello ()

16.

})

With this change, the User class can be safely reused in many scripts.

Dependencies should be loaded asynchronously

Because trying to load a script synchronously will cause the browser to lock up, which is very important, your script and your module should use the asynchronous loading mechanism. Require.js by default, all your modules are loaded asynchronously, and the functions of your module code are executed only after all dependencies have been loaded.

By using a closure, we can further take advantage of "use strict".

Modules should not rely on global variables

To further enhance our JavaScript code base, we have (almost) eliminated global variables (except for those provided by require.js, such as require () and define ()). Global variables are notorious potential "hidden dependencies" that enter modules that make code difficult to reuse or test.

Require.js also allows us to convert third-party global variables, require ()-through the padding function. In this example, lib/calculator creates a global calculator object, and the library is digitized.

Var require = {

1.

"shim": {

two。

"lib/calculator": {

3.

"export": "Calc"

4.

}

5.

}

6.

}

At this point, I believe you have a deeper understanding of "what are the characteristics of well-organized JavaScript code?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.