Analysis of analytical rules of modules in Seajs and summary of the use of modules

  This article mainly introduces the analytical rules of modules in Seajs and summarizes the use of modules, the need for friends can refer to the following

The SEAJS GitHub module logo has been relatively clear. But there is no exhaustive, especially when you need handwriting "module ID" and "module dependencies", or write their own automated tools to do transport (PS:SPM seemingly adaptable is not very strong also difficult to use, after all, the directory structure of each project may vary greatly, and difficult to change. Of course, if he's positioned as a package management tool and don't expect it to be the automated build tool for your project, the parsing rules for IDs need to be thoroughly understood. Precautions: 1. The top-level identity always resolves relative to the base base path. 2. Absolute and root paths are always relative to the current page resolution. 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 resolved relative to the current page. In   Seajs, the IDs of modules can be roughly divided into three kinds: "Relative identification", "Top level identification", "normal path", and normal path includes "absolute path", "Root path", etc.   Here the emphasis is on "relative identification" and "Top level identification". Relative identification means "./", ".. /"At the beginning, such as:"./othermodule ",". /lib/base ". The top-level identity refers to a file or directory (can contain: letter 、-、 _), such as: "App/widget/select"   need to write module ID three places:   code as follows: Define ("ID (1)", [".. /id2 (2) "], function (require, exports, module) {    var Modulea = require ('./modulea (3) ');}) Note: Whether it is define the first argument "module ID" or the second argument "dependent module ID" or "Require module ID", the final alignment criterion is "parsed file uri". Therefore, the three places that need to write IDs can be written in any way, as long as the final resolution to the same URI is considered to be the same module. In the process of parsing IDs, the alias and paths that are defined in Seajs.config are processed in advance.   Base Path resolution rule (layer 1th, its path does not depend on any settings) 1. You cannot use the top-level identity because the top-level identity is resolved relative to the base base path, so base itself can only use relative identification or root path. 2. Base default path is SEAJS Directory, other cases see SEAJS official website, if not SEAJS recommended source directory structure, try to manually set the base path. 3. "Relative identification": Resolution on the current page. Path resolution rule in paths (layer 1th, its path does not depend on any settings) 1. "Relative identification": Where to be referenced, the relative resolution position depends on where it is referenced, followed by local rules. 2. The fields in the paths are replaced in the way they are used in the variable, and then parsed. For example:     code is 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"); => conversion to: ". /.. /lib/jquery "//=> Loading: Mod/lib/jquery (Special note 1) ...//module Mod/f.js: ... require (" a/jquery "); => conversion to: ". /.. /lib/jquery "//=> loading: lib/jquery (pay special attention to 2) ... the path resolution rule in alias (layer 2nd, the path to itself can depend on the paths setting) 1. The rules for an alias are similar to paths, and the alias path can also use the "variable" 2 in paths. Reminder: Paths, alias, use "Top level id", "Root path", "absolute path", do not use "relative identity", because the module references at different depths will resolve to different paths. 3. "Relative identification": Where to be cited, the relative resolution position depending on where the reference is referred to, following local rules. Seajs.use path Resolution rule "relative identity": in relation to the current page parsing. Define defines module ID resolution rules (1)   (layer 3rd), the path can be set relative to the alias or paths: relative identification, top level identification, root path is recommended for top-level identification, or relative identification or root path if the module is not located within the base base path. Relative identification: Relative to the current page parsing   code is as follows://code block (2)//config-also use [code block (1)] in configuration  //module 1, no ambiguity, root path resolution define ("/app/src/module/base ", ..); Module 2, no ambiguity, top-level identification, relative to the base base path to resolve define ("App/src/module/base", ...); Module 3, ambiguous, relative identification, where the current page (referenced to the module's HTML page)//But other places even using the "surface of the same" ID ", may be resolved by different modules define ("./app/src/module/base ",..);     Module Dependency ID resolution rule (2)   (layer 3rd, path can be set relative to alias or paths) "relative identity": relative base Path resolution     code is as follows://code block (3)// Config-also uses the configuration  /no ambiguity in the code block (1), relative to the root path parsing define ("...", ["/app/src/module/base"], ...)//no ambiguity, top-level identification, resolution D relative to base path Efine ("...", ["app/src/module/base"], ...)//ambiguous, relative identification, here is the current module to resolve//The dependencies here appear to depend on ' Module 3 ' in "code block (2)"/ However, if the current module is not in the same directory as the current page, it will not be resolved to the ID resolution rule (3) of the other modules in Module 3   define ("...", ["./app/src/module/base"],..) module (level 3rd, road Diameter can be set relative to alias or paths: relative to base Path resolution   code is as follows://code block (4)//config-also using the configuration   define ("...") in [code block (1)]., [...], function (require) {   //No ambiguity, relative root path parsing     require ("/app/src/module/base");   Define ("...", [..], function (require) {   //No ambiguity, top-level identification, relative to base base path resolution     require ("App/src/modu Le/base "); });   Define ("...", [..], function (require) {   //ambiguous, relative identifier, here to resolve    ///dependencies in this case is dependent on "code block (2)" ' Module 3 '    /But if the current module is not in the same directory as the current page, it will not be parsed as ' Module 3 '     require ('./app/src/module/base ');   Special reminder: There are three places in the module where you need to write IDs, and you don't need to use strings that look the same, as long as they are parsed into the same module.   Summary: The 1.paths and alias settings are just equivalent to a variable, where it is used, where it is replaced with a set value and then parsed. 2. Use the "top identification" as much as possible. 3. If you can not use the "top-level identity", such as the directory across the larger, and so on, then try to set the alias or paths through a "non-relative path" identity to navigate to a directory, and then under this identity, and then define the ID.