ID和路径匹配原则.pdf

ID 和路径匹配原则 经常收到 seajs.use 某具名模块时发现其引⽤为 null 的问题，或是移动了⽂件位置 导致引⽤为 null 或 object is not function 的问题。⽐如这个 #954 ，这 个 #888 ，这个 #879 ，这个 #739 ，这个 #696 ，还有这个 seaj s/examples# 12 。 这些问题都指向 Sea.j s 的⼀个基本约定原则：ID 和路径匹配原则。 这是什么 所谓 ID 和路径匹配原则 是指，使⽤ seajs.use 或 require 进⾏引⽤的⽂件，如 果是具名模块 （即定义了 ID 的模块），会把 ID 和 seajs.use 的路径名进⾏匹配， 如果⼀致，则正确执⾏模块返回结果。反之，则返回 null。例如： seajs.use(lib/jquery , function($) { // use $}); 或 在模块中 require ： define(function(require, ex orts, module) { var $ = require(li 当 j Query ⽂件是下⾯的情况时，上述的变量 $ 能拿到正确的返回结果。 // ⽂件路径是 lib/jquery .js// ID 和实际路径匹配了 （.js 后缀会⾃动补上）de 下⾯的代码则返回 null ： // ⽂件路径是 lib/jquery .js// 但是 ID 是 lib/jquery .min.js// ID 和路径 ⽽匿名模块始终能正确返回结果： // lib/jquery .js// 匿名模块 不需要进⾏匹配// 但是⽂件中只能有⼀个 define 注意这⾥⽤于匹配的 ID 都是经过 alias 和 pa h 解析并且补完后缀之后 的。 为什么要有这个原则 回答这个问题前，请先阅读这篇⽂章：#426 。 ⾸先，Sea.j s 的模块启动接⼜秉承的是路径即 ID 的设计原则。seajs.use 的⽅法的 第⼀个参数被规定为⽂件路径 （⽽不是 ID ），这样的设计减轻了记忆模块 ID 的负 担，⽆论是匿名模块还是具名模块，开发 只需要知道⽂件放在哪⼉就⾏了。 进⼀步的，之所以有这个 ID 和路径匹配原则，是因为在 CMD 的书写规范中，⼀个 ⽂件对应⼀个模块，所有的模块都是匿名模块 （即 define(factory) 的形式）。 那么当 seajs.use 某模块时，这个模块对应的⽂件⾥的唯⼀的 define ⽅法理所当然 的是这个模块的执⾏代码，这时可以正确返回结果。 但是在⽣产环境下，静态⽂件不可避免地需要进⾏合并打包或 进⾏ combo ，以优化 请求数提⾼页⾯性能。这时，⼀个 j s ⽂件可能有很多 define() ⽅法。 define(funtion(require, ex orts, module) { // module a}); define(funtion(require, ex orts, module) { // module b}); define(funtion(require, ex orts, module) { // module c}); 那么请问，当 seajs.use 这个⽂件时，应该返回哪个模块？ 所以这时候 ID 就派上了⽤场，我们可以这样写： // ath/a.jsdefine( ath/a, funtion(require, ex orts, module) { define( ath/b, funtion(require, ex orts, module) { // module define( ath/c, funtion(require, ex orts, module) { // module 我们定义好每个模块的 id ，在 Sea.j s ⾥，那个和⽂件路径匹配的 ID 的模块就是这个 ⽂件的主模块。此时： seajs.use( ath/a, function(a) { // got a, not b or c}); 这个原则保证了我们能够⾃由合并模块来优化性能，seaj s-combo 和 spm-build 的构建 机制都是基于此原则。 在 RequireJS 中，也有类似的原则：h p://requirej /docs/errors.h ml#misma ch 更深⼀步 可能有⼈要问为啥⼀定要把