JavaScript库在全局命名空间中的作用-缺点？

Question

像Underscore.js和LoDash.js这样的JS库通常通过全局对象_提供函数。

_.map(...);
_.filter(...);

这些基本函数是Python中的全局函数和标准库的一部分：

map(...)
filter(...)

如果我把图书馆功能提升到全局功能..。

window.map = _.map;
window.filter = _.filter;

map(...);
filter(...);

..。除了全球名称空间污染之外，还会有哪些不利因素？

我一定要预料到任何性能问题吗？

它会导致某些浏览器中的错误吗？(例如，如果内置的JS函数被库函数覆盖，而库函数又依赖于本机函数)

链子还能用吗？

Answer 1

假设像这样的图书馆，

_ = (function(){

   lib = {};

   lib.function1 = function(){
      //code
   };
   lib.function2 = function(){
     this.function1();
   };

   //more code

   return lib;

})();

如果你用，

window.function2 = _.function2;
function2();

库在function2中使用"this“操作符。您的方式在这里更改了function2的范围。function2()调用将给出一个错误："function1未定义“。

Answer 2

有多种不利因素，但性能不太可能是其中之一。

如果两个库都有一个map()函数并且行为稍有不同怎么办？如果他们都将他们的map()放在全局空间中，您将无法访问其中的一个。而且您可能无法很容易地知道您实际想要的map()已被覆盖。

顺便说一句，map()和filter()是最新版本JS实现的一部分，但即使在那里，它们也是使用它们的对象的原型的一部分。所以你有Array.prototype.map()和Array.prototype.filter()。

Answer 3

下面是一些避免让map和filter这样的东西成为全局变量的原因：

1. 命名与其他试图执行类似操作的代码/库冲突，但不兼容。如果所有代码都使用大量的全局函数，那么单个全局函数的简单定义可能会完全破坏应用程序，因为它将重新定义用于代码中其他地方的函数。这本身就是尽可能少使用全球化的一个理由。在使用重要的第三方库的团队项目或项目中，这是不可能管理的，并且不可避免地会导致生产力的丧失，或者更糟糕的是，错误可能不会立即显现出来。
2. 当符号只是全局的时候，代码模块就不那么自我描述了。嗯，map()这个符号是从哪里来的。这是内置的吗？它是本地定义的吗？它是由某个图书馆定义的吗？要知道gutils.map()来自何处(来自gutils模块)要容易得多。与将事物分解为定义良好的模块相比，大量的全局任何东西都更不容易维护。
3. 将函数定义为它们所操作的对象上的方法有许多优点(例如，ES5、.map()和.filter()是数组对象上的方法，而不是泛型全局)。现在，将非标准方法添加到现有的内建对象(也是为了命名冲突原因)被认为是不好的做法，但鼓励添加实现标准行为的填充。

有关其他信息，请参阅这些参考资料：

如何以及为什么避免Javascript中的Globals

我听说全局变量不好，我应该使用什么替代方案？

基本Javascript命名模式

Javascript命名空间和模块

如何在JavaScript中声明命名空间？

至于性能的主题，它不应该是您的第一关注事项，而且在大多数代码中甚至可能不是一个相关的关注点。从健壮的、可维护的编码策略开始，然后只优化性能关键的小代码段比以性能为名牺牲健壮性要重要得多。

在性能至关重要的任何紧循环中，始终可以将任何函数赋值给局部变量以略微提高性能，这将比模块引用或全局引用(因为局部变量在全局变量之前被解析)更快。

因此，如果模块中有gUtils.map()，并且希望在特定函数中最大限度地提高性能，则可以这样做：

function x() {
    var map = gUtils.map;


    for (var i = 0; i < someBigNumber; i++) {
        map(...);
    }
}