The seajs github module identification has been relatively clear. But it is not covered in everything, especially when you need to hand-written [module ID] and [module dependency], or when you write your own automation tool to transport (ps:spm seems to be not very adaptable and not easy to use, after all, every The directory structure of the project may vary greatly and is not easy to change. Of course, if its positioning is a package management tool, don't expect it to be an automated construction tool for your project), and the ID parsing rules need to be thoroughly understood.
Notes:
1. The top-level identifier is always parsed relative to the base basic path.
2. The absolute path and the root path are always parsed relative to the current page.
3. The relative paths in require and require.async are parsed relative to the current module path.
4. The relative path in seajs.use is always parsed relative to the current page.
In seajs, the module ID can be roughly divided into three types: [relative identifier], [top level identifier], and [normal path].
Ordinary paths include "absolute path", "root path", etc.
Here we focus on [relative logo] and [top logo].
Relative identifiers refer to "./", "../", such as: "./OtherModule", "../lib/Base".
Top-level identifiers refer to files or directories (can contain: letters, -, _), such as: "app/widget/Select"
There are three places where module ID is required:
The code copy is as follows: define("id (1)",["../id2 (2)"], function(require, exports, module){
var moduleA = require('./moduleA (3)');
})
Note: Whether it is the first parameter [module ID] or the second parameter [module ID] or the [reliable module ID], the final comparison standard is [parsed file URI].
Therefore, these three places where IDs need to be written can be written in any way, and as long as they are finally parsed into the same URI, they are considered to be the same module.
During the process of parsing the ID, it will be processed in advance by alias and paths defined in seajs.config.
Base path resolution rules
(Layer 1, the path itself does not depend on any settings)
1. [Top Level Identification] cannot be used, because the top level Identification is parsed relative to the base basic path, so the base itself can only use [Relative Identification] or [root path], etc.
2. The default path of base is the seajs directory. For other cases, please refer to the seajs official website. If it is not the source code directory structure recommended by seajs, try to manually set the base path.
3. [Relative Identification]: Analyze relative to the current page.
Path resolution rules in paths
(Layer 1, the path itself does not depend on any settings)
1. [Relative Identification]: Where to be cited, the relative analytical location depends on the place being cited, and follows local rules.
2. The fields in paths will be replaced in the form of variables where they are used and then parsed.
for example:
Copy the code as follows: //Code Block (1)
//path definition:
seajs.config({
base:"./app/src",
path:{
"a":"../lib", //(1) Relative path
"lib":"path/to/lib", //(2) Top-level logo
"l2":"/lib" //(3) Root path
}
});
//Module mod/m/m.js:
...
require("a/jquery");
//=> Convert to: "../../lib/jquery"
//=> Loading: mod/lib/jquery (Special note 1)
...
//Module mod/f.js:
...
require("a/jquery");
//=> Convert to: "../../lib/jquery"
//=> Loading: lib/jquery (Special note 2)
...
Path resolution rules in alias
(In layer 2, the path itself can depend on the paths settings)
1. The rules of alias are similar to paths, and the alias path can also use "variables" in paths
2. Reminder: Try to use [top level identification], [root path], and [absolute path] in paths and alias, and do not use [relative identification], because modules of different depths will be parsed into different paths.
3. [Relative Identification]: Where to be cited, the relative analytical location depends on the place being cited, and follows local rules.
seajs.use path resolution rules
[Relative Identification]: Analyze relative to the current page.
define Define module ID parsing rules (1)
(In layer 3, the path can be set relative to alias or paths)
You can use: [Relative Identification], [Top Level Identification], [Root Path]
It is recommended to use [Top Level Identification]. If the module's location is not within the base path, use [Relative Identification] or [Root Path].
【Relative Identification】: Analysis relative to the current page
Copy the code as follows: // Code Block (2)
//config -- also use the configuration in [Code Block (1)]
// Module 1, no ambiguity, root path analysis
define("/app/src/module/Base", ..);
// Module 2, unambiguous, top-level identification, parsed relative to base basic path
define("app/src/module/Base", ..);
// Module 3, with ambiguity and relative identification, here relative to the current page (refer to the html page of this module)
// But even if [superficially the same "ID"] is used elsewhere, different modules may be parsed
define("./app/src/module/Base",..);
Module dependency ID resolution rules (2)
(In layer 3, the path can be set relative to alias or paths)
【Relative Identification】: Relative Base Basic Path Analysis
Copy the code as follows: //Code Block (3)
//config -- also use the configuration in [Code Block (1)]
//No ambiguity, relative to root path resolution
define("..", ["/app/src/module/Base"], ..)
// No ambiguity, top-level identification, relative to base basic path analysis
define("..", ["app/src/module/Base"], ..)
//There is ambiguity, relative to the current module.
//The dependency here seems to depend on `Module 3` in [Code Block (2)]
//But if the current module and the current page are not in the same level directory, it will not be parsed into `Module 3`
define("..", ["./app/src/module/Base"],..)
Require ID resolution rules for other modules within the module (3)
(In layer 3, the path can be set relative to alias or paths)
【Relative Identification】: Relative Base Basic Path Analysis
Copy the code as follows: //Code Block (4)
//config -- also use the configuration in [Code Block (1)]
define("..", [..], function(require){
//No ambiguity, relative to root path resolution
require("/app/src/module/Base");
});
define("..", [..], function(require){
// No ambiguity, top-level identification, relative to base basic path analysis
require("app/src/module/Base");
});
define("..", [..], function(require){
//There is ambiguity, relative to the current module.
//The dependency here seems to depend on `Module 3` in [Code Block (2)]
//But if the current module and the current page are not in the same level directory, it will not be parsed into `Module 3`
require("./app/src/module/Base");
})
Special reminder: There are three places in the module where IDs need to be written, and there is no need to use the same string, as long as it is parsed into the same module.
Summarize:
1. The settings of paths and alias are only equivalent to a variable. Where to use it, replace it with the set value and then parse it.
2. Use [top level logo] as much as possible.
3. If you cannot use the [top level identifier], such as the directory span is relatively large, try to set alias or paths to locate it to a directory through a [non-relative path] identifier, and then define the ID under this identifier.