seajs中模块ID注意事项,模块定义、模块加载、模块依赖的ID路径解析规则

seajs github 模块标识 已经说的相对清楚了。
但并没有面面俱到,特别是当你需要手写 【模块ID】和【模块依赖】的时候,或者自己写自动化工具来做 transport 的时候(ps:spm貌似适应性不是很强也不易用,毕竟每个项目的目录结构可能相差很大,且不易改变。当然如果他的定位是包管理工具就别指望它来做你的项目的自动化构建工具了),ID的解析规则就需要了解透彻了。

1. 顶级标识始终相对 base 基础路径解析。
2. 绝对路径和根路径始终相对当前页面解析。
3. require 和 require.async 中的相对路径相对当前模块路径来解析。
4. seajs.use 中的相对路径始终相对当前页面来解析。

seajs中,模块的ID大致可分为三种:【相对标识】、【顶级标识】、【普通路径】,
普通路径包括 “绝对路径”、“根路径”,等。

这里重点说明 【相对标识】 和 【顶级标识】。

相对标识 是指 "./","../" 开头的,如:"./OtherModule","../lib/Base"。
顶级标识 是指 以文件或目录(可以包含:字母、-、_)开头的,如:"app/widget/Select"

需要写模块ID的地方有三处:

define("id (1)",["../id2 (2)"],function(require,exports,module){
    var moduleA = require('./moduleA (3)');
})

注意:无论是define第一个参数【模块ID】还是第二个参数【依赖模块的ID】还是【require模块ID】,最终的比对标准是【解析后的文件URI】。

因此,这三处需要写ID 的地方可以以任意一种方式来写,只要最终解析为同一个URI,即被认为是同一个模块。

在解析ID的过程中,会预先经过 seajs.config 中定义的 alias 和 paths 的处理。

base 路径解析规则

(第 1 层,本身的路径不依赖于任何设置)
1. 不可使用【顶级标识】,因为顶级标识就是相对于 base 基础路径来解析的,因此 base 本身只能使用【相对标识】或【根路径】等。
2. base 默认路径为 seajs 的目录,其他情况参见seajs官网,如果不是seajs推荐的源码目录结构,尽量手动设置 base 路径。
3. 【相对标识】:相对于 当前页面 解析。

paths 中路径解析规则

(第 1 层,本身的路径不依赖于任何设置)
1. 【相对标识】:在哪里被引用,相对的解析位置视被引用的地方而定,遵循当地的规则。
2. paths中的字段会被以变量的方式在被使用的地方替换,然后再解析。
比如:

//代码块(1)
//path定义:
seajs.config({
    base:"./app/src",path:{
        "a":"../lib",//(1) 相对路径
        "lib":"path/to/lib",//(2) 顶级标识
        "l2":"/lib" //(3) 根路径
    }
});
//模块 mod/m/m.js: 
...
require("a/jquery");
//=> 转换为:"../../lib/jquery"
//=> 加载:mod/lib/jquery (特别注意 1)
...
//模块 mod/f.js:
...
require("a/jquery");
//=> 转换为:"../../lib/jquery"
//=> 加载:lib/jquery (特别注意 2)
...

alias 中路径解析规则

(第 2 层,本身的路径可以依赖于paths的设置)
1. alias 的规则类似于 paths,并且 alias 路径也可以使用 paths 中的“变量”
2. 提醒:paths、alias 中尽量使用【顶级标识】、【根路径】、【绝对路径】,不要使用【相对标识】,因为在不同深度的模块引用时会解析为不同的路径。
3. 【相对标识】:在哪里被引用,相对的解析位置视被引用的地方而定,遵循当地的规则。

seajs.use 路径解析规则

  1. 【相对标识】:相对于 当前页面 解析。

define 定义模块 ID 解析规则 (1)

(第 3 层,路径可以相对于 alias 或 paths 来设置)

  1. 可以使用:【相对标识】、【顶级标识】、【根路径】
  2. 推荐使用【顶级标识】,如果模块的位置不在 base 基础路径内,则使用【相对标识】或【根路径】。
  3. 【相对标识】:相对 当前页面 解析
// 代码块(2)
//config -- 还使用 [代码块 (1)]中的配置

// 模块1,无歧义,根路径解析
define("/app/src/module/Base",..);
// 模块2,无歧义,顶级标识,相对于 base 基础路径来解析
define("app/src/module/Base",..);
// 模块3,有歧义,相对标识,此处相对于 当前页面(引用到这个模块的html页面)
// 但其他地方即便使用 【表面上相同的“ID”】,也可能会被解析不同的模块
define("./app/src/module/Base",..);

模块依赖ID 解析规则 (2)

(第 3 层,路径可以相对于 alias 或 paths 来设置)
【相对标识】:相对 base 基础路径解析

//代码块(3)
//config -- 还使用 [代码块 (1)]中的配置

//无歧义,相对于根路径解析
define("..",["/app/src/module/Base"],..)
// 无歧义,顶级标识,相对于 base 基础路径解析
define("..",["app/src/module/Base"],..)
//有歧义,相对标识,此处相对于 当前模块 来解析
//此处的依赖看起来是依赖于【代码块(2)】中的 `模块3`
//但如果当前模块跟当前页面不在同一层目录下,就不会被解析为 `模块3`
define("..",["./app/src/module/Base"],..)

模块内 require 其他模块的ID 解析规则 (3)

(第 3 层,路径可以相对于 alias 或 paths 来设置)
【相对标识】:相对 base 基础路径解析

//代码块(4)
//config -- 还使用 [代码块 (1)]中的配置

define("..",[..],function(require){
    //无歧义,相对于根路径解析
    require("/app/src/module/Base");
});

define("..",function(require){
    // 无歧义,顶级标识,相对于 base 基础路径解析
    require("app/src/module/Base");
});

define("..",function(require){
    //有歧义,相对标识,此处相对于 当前模块 来解析
    //此处的依赖看起来是依赖于【代码块(2)】中的 `模块3`
    //但如果当前模块跟当前页面不在同一层目录下,就不会被解析为 `模块3`
    require("./app/src/module/Base");
})

特别提醒:模块内三处需要写ID的地方,不需要使用看起来相同的字符串,只要被解析为相同的模块即可。

总结:

  1. paths 和 alias 的设置仅仅相当于一个变量,在哪里使用,就在那里替换为设定的值,然后再解析。
  2. 尽可能的使用【顶级标识】。
  3. 如果不能使用【顶级标识】,比如目录跨越比较大等,则尽量设置 alias 或 paths 通过一个【非相对路径】 标识 定位到一个目录,然后在这个标识下,再定义ID。

参考 :
模块标识
配置

转载请注明来自[超2真人]
本文链接:http://www.peichao01.com/static_content/doc/html/seajs-id-parse-rule.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结