SEAJS Learning--module-id Specification

We believe that we have been able to complete a project with SEAJS, but there are still a lot of gaps in the project from the formal launch, there are many optimizations that need to be done, such as optimizing the number of requests and optimizing the file size.

When you use Seajs happy coding, you will also find that the module is too many, the number of requests too much of the problem. In this chapter, we will discuss how to optimize the SEAJS project, so that it can really achieve the standard to go online.

Before optimizing, let's discuss the module ID in Seajs, remember the module definition of CMD mentioned earlier? Define (id?deps?,factory), here side of the module ID, the official recommendation we do not write, through the tool to generate, then you know how this ID is generated, through what rules?

We'll take a look at this module ID in this section.

Take a look at where we will use the module ID. Three Places,

Define (id[1],[' id[2] '],function (require) {
var a = require ("id" [3]);
})

Whether it is define the first parameter "module ID" or the second parameter "ID of the dependent module" or "Require module ID", the final comparison criterion is the "parsed file uri".
Therefore, these three places need to write the ID can be written in any way, as long as the final resolution to the same URI, which is considered to be the same module.


A basic contractual principle of sea.js: **id and path matching principles * *.

The so-called **id and path matching principle * * refers to the file referenced with Seajs.use or require, if it is a named module (that is, the module that defines the ID), will match the ID and seajs.use path name, if the same, the correct execution of the module return results. Conversely, NULL is returned. For example:

Define (' path/module/a ', [],function (Require) {

})

In this example, the module ID is defined in order to path/moudle/a, so that the A module should be placed correctly in base (defined in config)/path/moudle/a.js, and Null is returned if A.js is not in that position.

As for why ' be sure to use the ID as a file path ', this piece please move [https://github.com/seajs/seajs/issues/930
]()

# # #在详细的讨论下 parsing rules for module_id

The module identifier in the Sea.js is a superset of the CommonJS module identity:

* A module identifies multiple components separated by a slash (/).
* Each item must be a small hump string,. Or.. 。
* The module ID may not contain the file suffix name, such as. js.
* The module ID can be a relative or top-level identity. If the first item is. Or.., the module identity is relative to the identity.
* The top-level identity is parsed based on the underlying path of the module system.
* Relative identification relative to the path of the module require is resolved.

Note that the identification that complies with the above specification is certainly the Sea.js module identification, but the module identification identified by Sea.js does not need to fully conform to the above specifications. For example, in addition to the small hump string of uppercase and lowercase letters, the Sea.js module identifier string can also contain underscores (_) and hyphens (-), and can even be an absolute path at the beginning of a protocol such as http:/, https://, file:///, and so on.

Relative identification

Relative identification with. First, it only appears in the module environment (define's factory method). Relative identities are always resolved relative to the URI of the current module:

In the factory of Http://example.com/js/a.js:
Require.resolve ('./b ');
= Http://example.com/js/b.js

In the factory of Http://example.com/js/a.js:
Require.resolve ('.. /C ');
= Http://example.com/c.js
Top-level identity

The top-level identity does not start with a dot (.) or slash (/) and is parsed relative to the underlying path of the module system (that is, the base path of the Sea.js):

Suppose the base path is: http://example.com/assets/

In the module code:
Require.resolve (' gallery/jquery/1.9.1/jquery ');
= Http://example.com/assets/gallery/jquery/1.9.1/jquery.js

The base path of the module system is the default value of base, which is related to the access path of the sea.js:

If the access path for Sea.js is:
Http://example.com/assets/sea.js

The base path is:
http://example.com/assets/
When the Sea.js access path contains a version number, base does not contain the seajs/x.y.z string. This is handy when there are multiple versions of Sea.js.

If the path to Sea.js is:
Http://example.com/assets/seajs/1.0.0/sea.js

The base path is:
http://example.com/assets/
Of course, you can also configure the base path manually:

Seajs.config ({
Base: ' http://code.jquery.com/'
});

In the module code:
Require.resolve (' jquery ');
= Http://code.jquery.com/jquery.js

# # #普通路径

An identity other than a relative and top-level identity is a normal path. The parsing rules for normal paths, like the <script src= "..." ></script> in HTML code, are resolved relative to the current page.

Assuming the current page is http://example.com/path/to/page/index.html

An absolute path is a normal path:
Require.resolve (' http://cdn.com/js/a ');
= Http://cdn.com/js/a.js

The root path is a normal path:
Require.resolve ('/js/b ');
= Http://example.com/js/b.js

The relative path in use is always a normal path:
Seajs.use ('./C ');
= = Loaded is the Http://example.com/path/to/page/c.js

Seajs.use ('.. /d ');
= = Loaded is the Http://example.com/path/to/d.js

Tips:

The top-level identity is always resolved relative to the base base path.
Absolute and root paths are always resolved relative to the current page.
Relative paths in require and require.async are parsed relative to the current module path.
Relative paths in Seajs.use are always resolved relative to the current page.
Auto-add rules for file suffixes

Sea.js when parsing the module identity, the JS extension (. js) is automatically added unless a question mark (?) or the last character in the path is a pound sign (#). If you do not want to add extensions automatically, you can include a pound sign (#) at the end of the path.

The ". js" suffix can be omitted:
Require.resolve (' http://example.com/js/a ');
Require.resolve (' http://example.com/js/a.js ');
= Http://example.com/js/a.js

The ". css" suffix cannot be omitted:
Require.resolve (' http://example.com/css/a.css ');
= Http://example.com/css/a.css

When there is a question mark in the path ("?") ), the suffix is not added automatically:
Require.resolve (' Http://example.com/js/a.json?callback=define ');
= Http://example.com/js/a.json?callback=define

When the path ends with a pound sign ("#"), the suffix is not added automatically, and the pound sign is automatically removed when parsing:
Require.resolve (' http://example.com/js/a.json# ');
= Http://example.com/js/a.json

# # #设计原则

The rules for module identification are above, and the core point of the design is:

Separation of concerns. For example, when writing module a.js, if you need to reference b.js, you only need to know b.js relative a.js relative path, no need to focus on the other.

Try to be consistent with the browser's parsing rules. For example, the root path (/XX/ZZ), the absolute path, and the non-top-level identity passed to the use method are parsed relative to the URL of the page in which it is located.

SEAJS Learning--module-id Specification