如何解决 Google Closure 命名空间地狱？

Question

我的新工作是使用 Google Closure 库编写面向组件的 JavaScript。我喜欢事件、组件、服务和模块。但这项工作非常艰巨，因为需要编写充满名称空间的代码。以下代码是典型的：

goog.provide(com.bin.slash.dot.closure.widget.SuperForm);

goog.require(com.bin.slash.dot.closure.widget.Avatar);
// ... ten require calls more...

com.bin.slash.dot.closure.widget.SuperForm = function() {
  goog.base(this);
  this._internal = new com.bin.slash.dot.closure.widget.Avatar(
    com.bin.slash.dot.closure.widget.Avatar.SRC_PATH);
};

我不敢相信这是真的。我不害怕输入所有这些，但我只是觉得逻辑在这个符号地狱中溶解和混乱。扫描非常困难，因此需要更多时间来了解发生了什么。 我的老板说，不鼓励写这样的快捷方式：

var SF = com.bin.slash.dot.closure.widget.SuperForm = function(){};

因为它们在编译后都会绑定到全局命名空间（窗口），所以它们可以干扰其他东西。

问题是如何避免这个符号地狱？

更新：我对我的开发人员流程进行了改进，解决了符号地狱问题。 现在我编写了经过优化的 JavaScript，然后由 Grunt 使用 sweet.js 宏自动编译：

// For each file I define three macros which are replaced 
// in the compile time with hell of a long paths.
macro dir { rule { $x } => { my.very.very.long.namespace $x } }
macro class { rule { $x } => { dir.NameOfMyClass $x } }
macro proto { rule { $x } => { class.prototype $x } }

dir.NameOfMyClass = function() {}; // yields: my.very.very.long.namespaceNameOfMyClass = function() {};
class.CONSTANT = "I don't know why we write constants into classes, not prototypes"; // yields: my.very.very.long.namespaceNameOfMyClass.CONSTANT = ...;
proto.method1 = function() {}; // yields my.very.very.long.namespaceNameOfMyClass.prototype.method1 = function(){};

所有由宏编译器产生的噪音都被优秀的shelljs去除了。

Answer 1

假设您正在使用 Closure 编译器，请考虑 goog.scope。有内置的编译器支持，可以在优化之前替换别名变量：

• Making Closure Library less verbose with goog.scope – 来自Closure Library wiki 的设计文档
• Google JavaScript Style Guide: Aliasing with goog.scope
• Documentation for goog.scope
• Source code example from Closure Library code

概括地说

• goog.provide 和 goog.require 语法不变；
• 您可以开始在作用域内声明非构造函数命名空间；
• 构造函数命名空间需要在重命名它们的范围之外声明。

考虑到上述指南，您的代码示例可能看起来像这样：

goog.provide('my.very.long.namespace.NameOfMyClass');
goog.require('my.very.long.namespace');

/** @constructor */
my.very.long.namespace.NameOfMyClass = function() { /*...*/ };

goog.scope(function() {
  var _ = my.very.long.namespace.NameOfMyClass;

  _.CONSTANT = 'I don\'t know why we write constants into classes, not prototypes';

  _.prototype.method1 = function() {};

}); // goog.scope

额外

由于我没有足够的声誉来添加评论：

我的老板说，不鼓励写这样的快捷方式：

var SF = com.bin.slash.dot.closure.widget.SuperForm = function(){};

因为它们都将绑定到全局命名空间（窗口） 编译后，所以它们可以干扰其他东西。

即使没有这些快捷方式，高级编译也可以将SF 或myVariable 等符号重命名为简单的ga。这可能会导致与外部代码（例如 Google Analytics）发生冲突。

在全局范围内防止此类冲突的闭包支持方法是在编译后引入立即调用的函数表达式 (source)。使用编译器标志：--output_wrapper "(function(){%output%})();"，或严格模式兼容的变体：--output_wrapper "(function(){%output%}).call(this);"。使用时，老板不鼓励的快捷方式将不会与外部符号发生冲突。

Answer 2

定义引用以简化 IMO 工作流程并没有错。

var 
widget = com.bin.slash.dot.closure.widget
widget.methA = function(){ widget.propertyA = 10}

命名空间是有目的的，虽然我不能谈论你的代码库，但可能有更好的方法来组织这个库。

Answer 3

使用立即函数创建单独的本地上下文怎么样：

(function () {
    var SF = com.bin.slash.dot.closure.widget.SuperForm = function(){};
}());

您的代码应该只放在这个函数中。这样您就永远不会覆盖任何全局变量。