service-worker - 在 Workbox 中使用 skipWaiting 和 clientsClaim 有什么缺点？

Question

默认 skipWaiting在 Workbox 中设置为 false。假设您仅使用 Workbox 创建的 service worker 进行缓存，将其设置为 true 有什么缺点吗？如果不这样做，您的应用程序的下一个构建版本将发送更新的资源 URL(来自 webpack)。这些 url 将在 Service Worker 的预缓存 list 中更新，但没有 skipWaiting ，更新后的 Service Worker 不会被激活以利用它们，直到用户关闭浏览器并重新打开。

这些更新的资源将被正确加载(webpack 将加载包含新哈希值的资源)，但它们永远不会被缓存，直到用户再次关闭所有运行 service worker 的打开浏览器，然后重新打开。在这种情况下，有什么理由不只是设置 skipWaiting对吗？

作为一个相关问题，clientsClaim 究竟是做什么的？控制？只需打开skipWaiting就可以解决上述问题；那么clientsClaim有什么作用呢？

Answer 1

作为背景，我建议阅读“The Service Worker Lifecycle”。它是从通用 Service Worker 的角度编写的，但这些要点也适用于 Workbox 驱动的 Service Worker。
这些概念也从使用 create-react-app 的角度进行了更详细的解释。 ，在这个“Paying Attention while Loading Lazily”谈话和微型网站。
Workbox 的实现
Workbox 使用 install事件处理程序在预缓存 list 中缓存新的或更新的条目(在需要时将 __WB_REVISION__ 查询参数附加到条目的 URL，以避免覆盖具有不同修订版本的现有条目)，并且它使用 activate事件处理程序删除不再在预缓存 list 中列出的以前缓存的条目。
如 skipWaiting为真，则 activate处理程序负责从缓存中清除过时的 URL，将在安装更新的 Service Worker 后立即执行。

Under these circumstances, is there any reason to not just set skipWaiting to true?

有 few risks使用 skipWaiting ，并且为了安全起见，我们默认在 Workbox 中禁用它。 (它在较旧的 sw-precache 生成的服务 worker 中默认启用。)
让我们假设一个场景，其中您的 HTML 加载缓存优先(通常是最佳实践)，然后在加载后的某个时间检测到 Service Worker 更新。
风险 1:延迟加载指纹内容
现代 Web 应用程序通常结合两种技术:仅在需要时异步延迟加载资源(例如，在单页应用程序中切换到新 View )和添加指纹(哈希)以根据 URL 包含的内容唯一标识 URL。
传统上，它要么是 HTML 本身(或一些包含路由信息的 JavaScript，这些信息也在页面生命周期的早期加载)包含对需要延迟加载的当前 URL 列表的引用。
假设最初加载的 Web 应用程序版本(在 Service Worker 更新发生之前)认为 URL /view-one.abcd1234.js需要加载才能渲染 /view-one .但与此同时，您已经为您的代码部署了更新，并且 /view-one.abcd1234.js已在您的服务器和预缓存 list 中替换为 /view-one.7890abcd.js .
如 skipWaiting为真，则 /view-one.abcd1234.js将作为 activate 的一部分从缓存中清除事件。作为部署的一部分，您可能已经从服务器中清除了它。因此该请求将失败。
如 skipWaiting为假，则 /view-one.abcd1234.js将继续在您的缓存中可用，直到 Service Worker 的所有打开客户端都已关闭。这通常是你想要的。
注意:虽然使用 Service Worker 可能会更容易遇到此类问题，但对于所有延迟加载版本化 URL 的 Web 应用程序来说，这都是一个问题。您应该始终进行错误处理以检测延迟加载失败并尝试通过例如强制重新加载您的页面来恢复。如果您拥有该恢复逻辑，并且您对该 UX 感到满意，您可以选择启用 skipWaiting反正。
风险二:不兼容逻辑的延迟加载
这与第一个风险类似，但它适用于您的 URL 中没有哈希指纹的情况。如果您部署了对 HTML 的更新以及对其中一个 View 的相应更新，则现有客户端可以结束延迟加载 /view-one.js 的版本。这与从缓存中获取的 HTML 的结构不符。
如 skipWaiting是假的，那么这不太可能发生，因为 /view-one.js从缓存加载的应该对应于从同一缓存加载的 HTML 结构。这就是为什么它是一个更安全的默认值。
注意:和以前一样，这不是 Service Worker 独有的风险——任何动态加载未版本化 URL 的 Web 应用程序最终可能会在最近的部署后加载不兼容的逻辑。

so what does clientsClaim do?

clientsClaim确保在服务 worker 激活后，该服务 worker 将立即控制范围内的所有不受控制的客户端(即页面)。如果您不启用它，那么在下一次导航之前它们将不会受到控制。
启用通常比 skipWaiting 更安全，如果您希望 Service Worker 尽早开始填充运行时缓存，这会很有帮助。
我会给你转介 section在 Service Worker Lifecycle 文档中了解更多信息。