编写用户脚本时是否真的需要立即调用函数表达式 (IIFE) 模式?
Is the Immediately-Invoked Function Expression (IIFE) pattern really necessary when writing userscripts?
我的问题与 What is the purpose of a self executing function in javascript? 非常相似,但它涉及用户脚本(专门针对 GreaseMonkey)。
我看到有些用户脚本以这种模式分发,有些则没有。
具有 IIFE 模式的脚本示例:(source)
// ==UserScript==
// (...)
// ==/UserScript==
(function(){
// if <condition>
document.location.href += '?sk=h_chr';
// ...
})();
没有它的脚本示例:(source)
// ==UserScript==
// (...)
// ==/UserScript==
window.location.href = "https://www.facebook.com/?sk=h_chr";
此外,我还发现TamperMonkey的"New script"模板遵循它,而GreaseMonkey和ViolentMonkey的模板则没有。
那么问题是,IIFE 模式在编写用户脚本时有用吗?
特别是,如果我的脚本在 strict
mode 中,并且我使用 let
而不是 var
。无论如何,据我所知,用户脚本中定义的函数和变量在全局页面范围内不可用。
谢谢。
functions and variables defined in userscripts are not made available in the global page scope
这不是真的。
用户脚本的工作方式是通过脚本注入(是的,这基本上是一种攻击)。用户脚本可以访问页面中的变量和函数的唯一方法是向页面公开用户脚本 - 因此页面可以访问用户脚本。
因此,在用户脚本中使用 IIFE 的主要原因是为了避免弄乱页面上的脚本 运行。
一些脚本注入系统可能在你背后的 IIFE 中透明地执行你的用户脚本(这就是 nodejs 对模块所做的 - 是的,它不是用户脚本系统,但它是一个执行此操作的软件示例)。在这种情况下,您不需要自己手动编写 IIFE 代码。我个人不知道哪个扩展会这样做,哪个不会,所以为了安全起见,我倾向于包括 IIFE。
如果您的代码没有定义任何新变量或函数,您也可以不使用 IIFE,因为您的代码中没有任何内容可以覆盖现有代码。
一般不会; IIFE 模式很少用于包装整个用户脚本(请参阅下面的边缘情况)。这是多年前的倒退,当时某些引擎(短暂地)默认情况下不包装脚本。
事实上,如果您包含已过时的 @unwrap
directive,脚本引擎现在都会忽略它。
以下是使用 IIFE 模式的一些原因:
- 这是在旧版本的 Violentmonkey(2018 或更早版本)中为整个脚本强制执行
strict
模式的唯一方法。
- 它可以抑制无害
Parsing error: 'return' outside of function
警告 如果您同时使用:(1) A script-wide return
和 (2) 外部 LINTer。
一些旧的 Greasemonkey 版本也会对此发出警告,同时仍然可以正常工作。
- (我以为还有第三种极端情况。但被打断了,不记得是什么了。)
考虑这个测试脚本:
// ==UserScript==
// @name _Scope and Strict-Mode Demo script
// @match https://whosebug.com/*
// @unwrap
// @grant none
// ==/UserScript==
/* eslint-disable no-multi-spaces, curly */
'use strict';
if (location.pathname.includes("/users/") ) {
console.log ("Terminating script early.");
return; // In external LINTers, this will cause a harmless warning.
}
var cantSeeMeInConsole = "neener neener";
window.canSomestimesSeeMe = "Howdy";
console.log (`In Strict mode: ${bInStrictMode() }; \`cantSeeMeInConsole\`: ${cantSeeMeInConsole}`);
function bInStrictMode () {
var inStrict = false;
var dummyObj = {};
Object.defineProperty (dummyObj, 'foo', {value: "bar", writable: false } );
try { dummyObj.foo = "fee"; }
catch (e) { inStrict = true; }
return inStrict;
}
- 运行 在 Firefox 和 Chrome.
- Safari 和 Opera 应该给出相同的结果。
- Microsoft Edge 可能 给出相同的结果。 (不过我不在乎有没有。)
- 运行 使用 Tampermonkey、Violentmonkey 和 Greasemonkey 4.
脚本范围:
在所有情况下,用户脚本都是 scoped/wrapped。该页面看不到代码,也看不到 cantSeeMeInConsole
.
等变量
当心 script page conflicts can still occur in @grant none
mode.
脚本沙盒:
额外的隔离适用,具体取决于:(a) 用户脚本引擎,(b) 浏览器,以及 (c) @grant
模式。
例如,使用 Greasemonkey 或更改授权模式会破坏页面查看 canSomestimesSeeMe
.
的能力
严格模式:
- 像这样将
'use strict';
放在最上面会将整个用户脚本切换到严格模式。
- 此外,在 Tampermonkey 的高级选项中,您可以将所有脚本的“严格模式”设置为 [Default/Always/Disabled]。
在相关说明中,如果脚本不使用 @run-at
设置,则使用 $(document).ready()
或其 shorthand.
没有意义
我的问题与 What is the purpose of a self executing function in javascript? 非常相似,但它涉及用户脚本(专门针对 GreaseMonkey)。
我看到有些用户脚本以这种模式分发,有些则没有。
具有 IIFE 模式的脚本示例:(source)
// ==UserScript==
// (...)
// ==/UserScript==
(function(){
// if <condition>
document.location.href += '?sk=h_chr';
// ...
})();
没有它的脚本示例:(source)
// ==UserScript==
// (...)
// ==/UserScript==
window.location.href = "https://www.facebook.com/?sk=h_chr";
此外,我还发现TamperMonkey的"New script"模板遵循它,而GreaseMonkey和ViolentMonkey的模板则没有。
那么问题是,IIFE 模式在编写用户脚本时有用吗?
特别是,如果我的脚本在 strict
mode 中,并且我使用 let
而不是 var
。无论如何,据我所知,用户脚本中定义的函数和变量在全局页面范围内不可用。
谢谢。
functions and variables defined in userscripts are not made available in the global page scope
这不是真的。
用户脚本的工作方式是通过脚本注入(是的,这基本上是一种攻击)。用户脚本可以访问页面中的变量和函数的唯一方法是向页面公开用户脚本 - 因此页面可以访问用户脚本。
因此,在用户脚本中使用 IIFE 的主要原因是为了避免弄乱页面上的脚本 运行。
一些脚本注入系统可能在你背后的 IIFE 中透明地执行你的用户脚本(这就是 nodejs 对模块所做的 - 是的,它不是用户脚本系统,但它是一个执行此操作的软件示例)。在这种情况下,您不需要自己手动编写 IIFE 代码。我个人不知道哪个扩展会这样做,哪个不会,所以为了安全起见,我倾向于包括 IIFE。
如果您的代码没有定义任何新变量或函数,您也可以不使用 IIFE,因为您的代码中没有任何内容可以覆盖现有代码。
一般不会; IIFE 模式很少用于包装整个用户脚本(请参阅下面的边缘情况)。这是多年前的倒退,当时某些引擎(短暂地)默认情况下不包装脚本。
事实上,如果您包含已过时的 @unwrap
directive,脚本引擎现在都会忽略它。
以下是使用 IIFE 模式的一些原因:
- 这是在旧版本的 Violentmonkey(2018 或更早版本)中为整个脚本强制执行
strict
模式的唯一方法。 - 它可以抑制无害
Parsing error: 'return' outside of function
警告 如果您同时使用:(1) A script-widereturn
和 (2) 外部 LINTer。
一些旧的 Greasemonkey 版本也会对此发出警告,同时仍然可以正常工作。 - (我以为还有第三种极端情况。但被打断了,不记得是什么了。)
考虑这个测试脚本:
// ==UserScript==
// @name _Scope and Strict-Mode Demo script
// @match https://whosebug.com/*
// @unwrap
// @grant none
// ==/UserScript==
/* eslint-disable no-multi-spaces, curly */
'use strict';
if (location.pathname.includes("/users/") ) {
console.log ("Terminating script early.");
return; // In external LINTers, this will cause a harmless warning.
}
var cantSeeMeInConsole = "neener neener";
window.canSomestimesSeeMe = "Howdy";
console.log (`In Strict mode: ${bInStrictMode() }; \`cantSeeMeInConsole\`: ${cantSeeMeInConsole}`);
function bInStrictMode () {
var inStrict = false;
var dummyObj = {};
Object.defineProperty (dummyObj, 'foo', {value: "bar", writable: false } );
try { dummyObj.foo = "fee"; }
catch (e) { inStrict = true; }
return inStrict;
}
- 运行 在 Firefox 和 Chrome.
- Safari 和 Opera 应该给出相同的结果。
- Microsoft Edge 可能 给出相同的结果。 (不过我不在乎有没有。)
- 运行 使用 Tampermonkey、Violentmonkey 和 Greasemonkey 4.
脚本范围:
在所有情况下,用户脚本都是 scoped/wrapped。该页面看不到代码,也看不到 cantSeeMeInConsole
.
等变量
当心 script page conflicts can still occur in @grant none
mode.
脚本沙盒:
额外的隔离适用,具体取决于:(a) 用户脚本引擎,(b) 浏览器,以及 (c) @grant
模式。
例如,使用 Greasemonkey 或更改授权模式会破坏页面查看 canSomestimesSeeMe
.
严格模式:
- 像这样将
'use strict';
放在最上面会将整个用户脚本切换到严格模式。 - 此外,在 Tampermonkey 的高级选项中,您可以将所有脚本的“严格模式”设置为 [Default/Always/Disabled]。
在相关说明中,如果脚本不使用 @run-at
设置,则使用 $(document).ready()
或其 shorthand.