4

在 RequireJS 文档（http://requirejs.org/docs/api.html#modulename）中，我无法理解这句话。

您可以自己显式命名模块，但这会降低模块的可移植性

我的问题是

  1. 为什么显式命名模块会降低可移植性？
  2. 何时需要显式命名模块？
4

2 回答 2

4

为什么显式命名模块会降低可移植性？

如果您没有明确地为模块命名，RequireJS 可以随意命名它，这使您可以更自由地使用可用于引用模块的名称。假设您有一个模块文件bar.js。你可以给 RequireJS 这个路径：

paths: {
    "foo": "bar"
}

您可以在 name 下加载模块"foo"。如果您在define调用中为模块指定了名称，那么您将被迫使用该名称。这个问题的一个很好的例子是 jQuery。碰巧 jQuery 开发人员已经决定（我看不出有什么好的理由）"jquery"在 jQuery 代码中硬编码模块名称。偶尔有人会抱怨他们的代码不起作用，他们paths有这个：

paths: {
    jQuery: "path/to/jquery"
}

由于硬编码的名称，这不起作用。paths配置必须使用 name ，"jquery"全部小写。（map配置可用于映射"jquery"到"jQuery"。）

何时需要显式命名模块？

当没有其他方法命名模块时需要它。一个很好的例子是r.js将多个模块连接到一个文件中。如果模块在连接期间没有命名，则无法引用它们。因此r.js，为它连接的所有模块添加显式名称（除非您告诉它不要这样做或模块已经命名）。

有时我对我所谓的“胶水”或“实用程序”模块使用显式命名。例如，假设 jQuery 已经通过scriptRequireJS 之前的元素加载，但我还希望我的 RequireJS 模块能够要求模块jquery访问 jQuery，而不是依赖于全局$. 如果我想在没有全局 jQuery 的上下文中运行我的代码，那么我不必针对这种情况修改它。我可能有一个这样的主文件：

define('jquery', function () {
    return $;
});

require.config({ ... });

该jquery模块仅用于满足需要 jQuery 的模块。将其放入单独的文件中没有任何好处，并且要正确引用它，必须明确命名。

于 2015-02-11T23:17:02.260 回答
1

这就是为什么命名模块不那么便携的原因，来自 Sitepen 的“AMD，The Definite Source”：

AMD 也是“匿名的”，这意味着模块不必硬编码任何对其自身路径的引用，模块名称仅依赖于其文件名和目录路径，大大简化了任何重构工作。

http://www.sitepen.com/blog/2012/06/25/amd-the-definitive-source/

并且来自 Addy Osmani 的“编写模块化 javascript”：

使用匿名模块时，模块身份的概念是 DRY，避免文件名和代码重复变得微不足道。由于代码更具可移植性，因此可以轻松地将其移动到其他位置（或文件系统周围），而无需更改代码本身或更改其 ID。module_id 等效于简单包中的文件夹路径，并且在包中不使用时。开发人员还可以在多个环境中运行相同的代码，只需使用与 r.js 等 CommonJS 环境配合使用的 AMD 优化器。

http://addyosmani.com/writing-modular-js/

为什么需要一个明确命名的模块，同样来自 Addy Osmani 的“编写模块化 javascript”：

module_id 是一个可选参数，通常仅在使用非 AMD 连接工具时才需要（可能还有其他一些有用的边缘情况）。

于 2015-02-11T18:34:35.623 回答