看看David Fowler的这段 JS 代码,他用一个匿名的自我执行方法包装了每个“类”,并在其中发送了 jQuery 和 window。我知道这是一种确保 $ 和 window 实际上是您期望它们成为的全局 jQuery 和 windows 变量的方法。
但这不是有点过度保护吗?您是否应该保护自己免受其他人更改 $ 和 window 变量的影响-实际上是否有这样做的代码,如果有,为什么?另外,像这样包装所有东西还有其他好处吗?
看看David Fowler的这段 JS 代码,他用一个匿名的自我执行方法包装了每个“类”,并在其中发送了 jQuery 和 window。我知道这是一种确保 $ 和 window 实际上是您期望它们成为的全局 jQuery 和 windows 变量的方法。
但这不是有点过度保护吗?您是否应该保护自己免受其他人更改 $ 和 window 变量的影响-实际上是否有这样做的代码,如果有,为什么?另外,像这样包装所有东西还有其他好处吗?
如果我没记错的话,除了 jQuery 之外还有其他一些库使用 $.
使用函数上下文创建本地/函数范围的概念就是为了保护您自己的代码。如果您希望 Javascript 代码在可能加载多个其他(甚至未知)脚本的环境中运行,这尤其有意义。
因此,如果在您自己之前加载的其他一些 Javascript 代码分配window.$
了其他一些值(例如,它可能会加载原型框架),那么如果您尝试访问 jQuery 特定的东西,那么您的代码已经搞砸了。
还有一点是“ a--hole ”效应。有人创建了一条线
window.undefined = true;
...
现在,您的所有检查undefined
都将失败。但是通过显式创建这些变量/参数并用您期望的值填充它们,您可以避免所有这些问题。
(function(win, doc, $, undef) {
}(window, window.document, jQuery));
通常,大多数顶级 JavaScript 代码都应该包装在IIFE中,无论它们是否传递了特定的变量。这可以防止创建的变量var
污染全局范围。
另一个小好处是缩小:如果你缩小你的代码,window
通过将它作为参数传入一个“局部变量”允许缩小器重命名它。但是,如果您使用 gzip 压缩,这种好处就会消失,因此这并不是真正的胜利。
大多数人只是为他们的 IIFE 选择一种模式并坚持下去,所以在他的情况下,他决定这是他们编写.js
文件的方式,并且他这样做是一致的。拥有一个统一的标准本身就很有价值。
为了澄清,代码可以写成稍长的形式
(function () {
var $ = jQuery;
var window = window;
// ...
}());
匿名函数内部的代码是函数作用域,因此它可以防止与全局变量发生冲突。
想象一下,如果每个 jQuery 插件都没有包装在匿名函数中,那么就会有一个全局变量地狱。
这只是为了维护完整性。$ 可以是原型,因此如果其他人添加了覆盖 $ 的库/变量,则发送 jQuery 作为参数将保存您的代码。
关于第二个参数“窗口”,我将其视为您要编写的模块。