require.js in-depth understanding of require.js features_javascript class library

Now, Require.js is my favorite way to program Javascript. It breaks the code into smaller pieces and makes it easier to manage. The Require.js Optimizer can help us disperse a larger application into multiple smaller applications, connect them through dependencies, and finally merge them during compilation and packaging. These reasons lead us to use require.js.

So, let’s take a look at the awesome features of require.js!

Compatible with CommonJS

AMD (Asynchronous Module Definition Specification) emerged from the CommonJS working group. CommonJS aims to create a Javascript ecosystem. An important part of CommonJS is transport/c, the predecessor of AMD, and require.js is an implementation of this specification.

The syntax difference between the CommonJS module and the AMD module is mainly due to the fact that AMD needs to support the asynchronous features of the browser. The CommonJS module needs to be executed synchronously, for example:

Copy code The code is as follows:

var someModule = require( "someModule" );
var anotherModule = require( "anotherModule" );

exports.asplode = function() {
SomeModule.doTehAwesome();
AnotherModule.doMoarAwesome();
};

AMD modules load modules asynchronously, so the module definition requires an array as the first parameter, and the callback function after the module is loaded is passed in as the second parameter.

Copy code The code is as follows:

define( [ "someModule"], function( someModule ) {
Return {
asplode: function() {
                                   someModule.doTehAwesome();

                                                        // This will be executed asynchronously
              require( [ "anotherModule" ], function( anotherModule ) {
                 anotherModule.doMoarAwesome();
            });
}
};
});

However, AMD is also compatible with CommonJS syntax in require.js. By wrapping the CommonJS module with AMD's define function, you can also have a CommonJS module in AMD, for example:

Copy code The code is as follows:

define(function(require, exports, module)
var someModule = require( "someModule" );
var anotherModule = require( "anotherModule" );

SomeModule.doTehAwesome();
AnotherModule.doMoarAwesome();

exports.asplode = function() {
          someModule.doTehAwesome();
         anotherModule.doMoarAwesome();
};
});

In fact, require.js interprets the module content of the callback function through the function .toString, finds its correct dependencies, and turns it into a normal AMD module. It should be noted that if you write a module in this way, it may be incompatible with other AMD loaders, because it violates the AMD specification, but it can understand the writing of this format very well.

What's happening here is that require.js actually does the function.toString callback function to parse the contents of the module and find the correct dependencies, just like it would if it were a normal AMD module. It's important to note that if you choose to write modules this way, they will most likely be incompatible with other AMD module loaders, as this goes against AMD specifications, but it's good to know that this format exists!

CDN fallback

Another hidden gem of require.js is that it supports falling back to loading the local corresponding library when the CDN is not loaded correctly. We can achieve this through require.config:

Copy code The code is as follows:

requirejs.config({
Paths: {
jquery: [
               '//cdnjs.cloudflare.com/ajax/libs/jquery/2.0.0/jquery.min.js',
             'lib/jquery'
]
}
});

No dependencies? Object literal? no problem!

When you write a module without any dependencies and just return an object containing some functional functions, then we can use a simple syntax:

Copy code The code is as follows:

define({
forceChoke: function() {

},
forceLighting: function() {

},
forceRun: function() {

}  
});

Very simple and useful if the module is just a collection of functions, or just a data package.

Circular dependencies

In some cases, we may need module moduleA and the functions in moduleA need to depend on some applications. This is circular dependency.

Copy code The code is as follows:

// js/app/moduleA.js
define([ "require", "app/app"],
function(require, app) {
         return {
foo: function(title) {
              var app = require( "app/app" );
                   return app.something();
            }
}
}
);

Get the module’s address

If you need to get the address of the module, you can do this...

Copy code The code is as follows:

var path = require.toUrl("./style.css");

BaseUrl

Usually, when performing unit testing, your source code may be placed in a folder similar to src, and at the same time, your tests may be placed in a folder similar to tests. This can be difficult to get the test configuration right.

For example, we have an index.html file in the tests folder and need to load tests/spec/*.js locally. And assuming, all source code is in src/js/*.js, and there is a main.js in that folder.

In index.html, do not set data-main when loading require.js.

Copy code The code is as follows:

<script><br> require( [ "../src/js/main.js" ], function() {<br> ​ require.config({<br> baseUrl: "../src/js/"<br> });<br> <br> ​ require([ <br> "./spec/test.spec.js",<br> "./spec/moar.spec.js"<br> ], function() {<br>                 // start your test framework<br> });<br> });<br> </script>

You can find main.js loaded. However, since data-main is not set, we need to specify a baseUrl. When using data-main, baseUrl will be automatically set according to the file it is set to.

Here, you can see main.js being loaded. However, since it does not load data in the main script tag, you must specify a base. When the data is primarily for baseURL it is inferred from the location in the main file. By customizing baseUrl we can easily store test code and application code separately.

JSONP

We can handle JSONP terminal like this:

Copy code The code is as follows:

require( [
"http://someapi.com/foo?callback=define"
], function (data) {
console.log(data);
});

For non-AMD libraries, use shim to solve

Under many requests, we need to use non-AMD libraries. For example, Backbone and Underscore are not adapted to AMD specifications. And jQuery actually just defines itself as a global variable named jQuery, so there is nothing to do with jQuery.

Fortunately, we can use shim configuration to solve this problem.

Copy code The code is as follows:

require.config({
Paths: {
"backbone": "vendor/backbone",
"underscore": "vendor/underscore"
},
shim: {
“backbone”: {
deps: [ "underscore" ],
Exports: "Backbone"
},
"underscore": {
Exports: "_"
}
}
});