【发布时间】:2020-07-08 21:07:54
【问题描述】:
我目前正在开发一个用户脚本,可以在我离开公司后使用几年。目标受众具有基本的计算机知识——足以填写一个简单的配置菜单。
我担心脚本可能会中断,因为 IT 部门可能会移动我在 @include 中列出的网页。我可以记录如何修复脚本,但我想针对我知道非常无能的 IT 部门进行防御性编程。我知道我可以做到以下几点:
- 允许用户在配置页面中指定 URL。
- 将
@include设置为非常通用的https://*.edu/*,并使用if语句在执行命令之前使用window.location.href确定我们在用户指定的URL 上。
对此解决方案的一些担忧:我希望脚本可以在机构之间轻松重复使用,这就是为什么我提到 *.edu 而不是 specificschool.edu。上述配置将使脚本在任何.edu 网站的几乎每个页面上执行,但由于if 语句,这些操作只会在它们在网页上时发生。这似乎非常低效,但我知道这可能是在便于携带和效率之间进行权衡。
有没有更好的方法来做到这一点?
【问题讨论】:
-
这似乎非常低效 不是真的 - 这正是我会做的。 (这就是我已经为我的一些用户脚本所做的)鉴于网站已经经常尝试让您的机器运行的垃圾 JS 负载,每个页面加载上的额外
if语句是 nothing担心。易读性和可维护性远比优化几分之一微秒更有价值。 -
所有主要的用户脚本管理器(Tampermonkey、Greasemonkey、Violentmonkey)都允许用户添加自己的包含/排除,甚至覆盖脚本的内置。
-
请参阅我们姊妹网站 Software Engineering 的元网站上的 Why is “Is it possible to…” a poorly worded question? 以及整个 Stack Exchange 元网站上的 Question closed because yes/no answer,以了解为什么“是/否”问题通常会被关闭-主题以及您可以做些什么来改进它。此外,询问“更好的方法”的问题是基于观点的题外话,除非它们包含客观可量化的“更好”的精确定义。
标签: javascript tampermonkey userscripts defensive-programming greasemonkey-4