41

为什么不将它用作 Javascript 的通用组件模式，包括浏览器执行的 Javascript？

乍一看，这似乎是一种将我目前正在从事的项目模块化的好方法，该项目由一个大型 Javascript 代码库组成，有很多组件，其中一些组件相互交互。

4

1 回答 1

73

CommonJS 绝对适合浏览器，但有一些注意事项。CommonJS 模块模式非常好（在我看来是有偏见的），也是为 ECMAScript Harmony（计划中的 JavaScript 语言的下一个版本）提出的模块系统的一个很好的垫脚石。具体来说，Harmony 模块将无法访问全局（“窗口”）对象。

有些人声称 CommonJS 模块不适合浏览器的原因是，如果没有服务器端的帮助，它们就无法通过 <script> 标签加载。例如，假设您有一个导出“convertToHTML”函数的降价库。然后，您可以制作一个如下所示的模块：

var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
    // do something then call convertToHTML
}

由于某些原因，这不能通过脚本标签起作用（范围没有被包装，因此 convertToHTML 会附加到窗口，通常不会定义 require 并且需要为每个模块单独创建导出）。

带有少量服务器端帮助的客户端库可以允许通过脚本标签轻松加载。或者，通过 XMLHttpRequest 加载脚本并执行 eval() 的客户端库也可以工作，尽管调试体验通常不那么好。

现在一个相当合理的解决方案是RequireJS，尽管它也是 CommonJS 成员之间争论不休的主题。使用 RequireJS，你可以像这样编写你的模块：

define(function(require, exports, module) {

var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
    // do something then call convertToHTML
}

});

我们所做的只是在模块周围添加了 define() 位。（你也可以让服务器很容易地做到这一点，这样你甚至不需要手动输入定义部分）。

我个人在几个项目中使用了 RequireJS，发现它是一种无需服务器端位即可使用 CommonJS 模块的简单方法。还有许多其他解决方案，如果您不依赖于运行静态 JS 文件，标准 CommonJS 模块是一个不错的选择。

（ObDisclaimer：我启动了 CommonJS 项目，所以我显然有偏见。）

于 2011-01-24T04:39:41.810 回答