模块加载.PDFVIP

第 1 章 1 模块加载 想想最简单的script标签，它在 1995 年被引入，仍然是嵌入JavaScript 到浏览器的 入口。不幸的是，如果你想构建复杂的应用程序，script 遇到了一些问题： y script把代码加载和执行合并在一起了，程序员需要很好地控制这两个阶段。 y script 是同步的，阻塞了浏览器的排版 绘画周期直至脚本下载完成。这就是为 / 什么当前的性能指导里推荐把script标签移到页面的底部。好消息是HTML 现 在提供了async和defer 属性，所以这个问题随着时间的推移或许会改善一些。 y script 有一个共享的全局上下文，并且没有正式的命名空间和安全性存在。当你 只是试图保护自己的代码免受你自己的错误所累时，这已经够糟糕的了，但是当你 的代码和其他未知的第三方代码一起运行时这更将会变成一场灾难。 y script 不知道和其他脚本的关系，一个脚本可能依赖另一个脚本，但是没有方法 来描述它。如果script 在页面中的顺序出错了，整个应用程序可能就失败了。 这些问题的根本原因在于，不像当今其他编程环境，浏览器中的JavaScript 没有内置的 模块（在“加载包和模块”中定义）概念。对于小段的脚本，这没什么，但是小段的脚 本有可能会慢慢长成一个很成熟的应用程序。 为了防止代码受干扰，许多JavaScript 库用一个全局变量来保存库里的所有方法。例 如，假设“Code Ninja”库实例化一个名为NINJA 的全局变量，并且给它提供如NINJA. throwShuriken() 的方法，在这里NINJA可以被看作一种命名空间，这可以解决上面的 第一个问题。 YUI 3 走得更进了一步，在YUI 3 中有一个全局的YUI 对象，但是你在内外都用到了它。 2 你不只是把YUI 作为一个命名空间，还可以调用YUI().use() 并在use()里的回调函数 里写下你的代码。在这个作用域里有一个私有的库实例叫做Y，它可以斜体访问到YUI 1 的一些方法如Y.one() 和一些对象如Y.AutoComplete。 YUI 3 这一举措的弊端是乍看起来很怪异。 这一举措的优点是： y YUI 可以解耦载入注册和执行阶段，YUI.add() 通过YUI 全局对象注册代码作为一 个模块并且按需加载，YUI().use() 可以在一个安全的沙箱里访问这些模块。 y YUI 可以同步或异步加载模块，因为注册和执行现在是分开的。 y 除了一些静态方法以外，YUI 避免使用共享的全局上下文，带有API 信息的Y 实例 是私有的，不可能被外面的沙箱所覆盖。 y YUI 支持真正的依赖逻辑，当你用YUI.add() 注册一个模块时，可以包含一些其他 模块、CSS 资源等元数据。YUI().use() 用这个信息来构建依赖树、获取需要完成 树的模块和跳过已经存在的模块。YUI 甚至可以根据浏览器特性来按条件加载模块， 这样你就可以不用针对不同的环境来写优化代码了，还可以让你在支持更旧的、更 低特性的浏览器的同时，不用针对现代浏览器加载不需要的代码。 YUI 的模块和加载系统在2007 年年中的时候开始做，这个系统在2009 年因为YUI 3 的 发布又重新被修改。近年来，JavaScript 模块已经理所应当地变成了一个热门话题，服 务器端的JavaScript 环境现在提供了CommonJS 模块格式的原生支持。Dojo 工具箱已经 采用了AMD 模块作为它的原生格式。将来的ECMAScript 标准也可能会把模块支持加 入JavaScript 内核中。 就像在“序言”中所说的那样，目前有很多好的JavaScript 库可以用，它们都有自己的 设计哲学和优势。如果你正在寻找一个符合YUI 的设计目标的单一功能，模块系统是一 个很好的开始。模块系统保证了代码的安全和封装性，它提供了智能默认设置的同