我刚刚开始查看 V3 清单要求并有以下问题。
我目前在我的 background.js var settings = new usersettings();
中使用 usersettings 从 chrome.storage.local 获取所有设置一次,然后如果设置属性发生更改,则将其保存回存储。
我是否正确理解每次使用 V3 时我需要使用设置中的值,例如 chrome.storage?此外,检索存储的唯一方法是/将是以下;
chrome.storage.local.get(['key'], function(result) {
console.log('Value currently is ' + result.key);
});
我不是专业的软件工程师,但每次我需要读取布尔设置时都使用上述代码似乎效率很低,不仅会减慢扩展速度,还会创建更多代码。我读到 V3 将利用 promises 是否可以与 chrome.storage.local.get 一起使用?
我使用本地消息传递主机。我在后台启动时调用 chrome.runtime.connectNative 并保持端口打开,这意味着 Google Chrome 启动的本机主机也运行。我找不到任何关于本机消息传递应该如何与服务工作者一起工作的信息。 chrome.runtime.connectNative 对服务工作者还有用吗?本机主机是否会随着 Service Worker 启动和停止?如果这样做,任何本机代码如何向扩展程序发送消息?
以下策略是个好主意吗?背景为“persistent”:false 的 Manifest V2 是否与 Service Worker 相同?换句话说,我可以先让我的代码在 V2 中使用非持久性 background.js 运行,而不是对 V3 进行重大更改吗?
我的本机主机将一些 javascript 传递给我的扩展程序,而扩展程序又通过脚本标记添加它。我在 V3 中读到 javascript 无法通过外部源检索。有没有人从 Google 看到有关本地主机是否会被视为外部来源的任何信息?一方面,我当然可以看到根据定义本机主机代码是外部的,但是,本机主机(至少对于 Windows PC)比从某些外部 url 获取代码的扩展具有更高的安装标准和用户权限要求.这就是我提出问题的原因。
当 V2 更新将被拒绝时,有人知道水晶球吗?
答案 0 :(得分:0)
TL;DR ManifestV3 仍然是一个半破的玩具,无法处理许多非平凡的场景。
<块引用>每次我需要使用 chrome.storage 的设置值时使用 V3
是的。
如果您的数据对象不大,那应该没有问题。
如果有疑问,请在您的代码中使用 devtools 分析器或 performance.now()
来衡量影响。
本地消息传递主机
它暂时坏了。
我看到一个有点相关的 https://crbug.com/1030305,但也许您应该打开一个新问题。
背景为“persistent”:false 的 Manifest V2 是否与 Service Worker 相同?
是的,概念上。
但是,由于 Service Worker 的劣势,可能会有差异,因为这仍然是一种不成熟的 Web 技术,因此它不支持我们已经习惯的东西,例如动态脚本加载、ES 模块、剪贴板处理、DOM 解析,以及更多。
我可以先让我的代码在 V2 中使用非持久性 background.js 运行,而不是对 V3 进行重大更改吗?
我的本机主机将一些 javascript 传递给我的扩展程序,而扩展程序又通过脚本标记添加它。
绝对禁止。
此代码不是扩展包的一部分,因此网店审核者无法对其进行验证。
当 Chromium 团队宣布他们的 Tampermonkey 解决方案和允许安装外部用户脚本的类似扩展时,将揭示替代方案。
同时,尝试切换到声明式方法:在 JSON 中创建规则定义,由您的扩展代码处理。
V2 更新何时会被拒绝?
可能是明年。
目前还没有官方公告,但如果 Chromium 开发人员有一点良心,他们不会禁用 ManifestV2,直到他们解决 V3 中的全部或大部分问题,这可能会在明年发生。
目前几乎没有针对 ManifestV3 问题的积极开发(其他领域,如 DevTools 看到的有意义的活动增加了约 100 倍),并且看到 Chromium 团队在过去五年中实际上如何忽略了扩展作者的大部分反馈,但事实并非如此非常令人鼓舞...