为什么self.skipWaiting()和self.clients.claim()不是服务工作者的默认行为

问题描述 投票:0回答:1

我正在为我的论文研究服务工作者。我理解生命周期是如何工作的,但是我无法理解服务工作者的默认更新行为。

安装新服务工作程序时,安装旧服务工作程序时,服务工作者必须等待激活。使用self.skipWaiting()和self.clients.claim(),可以完全激活服务工作者并控制页面。我不明白为什么这不是默认行为。我能找到的主要原因是保持代码和数据的一致性(https://redfin.engineering/service-workers-break-the-browsers-refresh-button-by-default-here-s-why-56f9417694)。通过对生命周期的一些基本了解,当服务工作者更新或我遗漏某些内容时,是否应该保持代码和数据的一致性?还有其他原因吗?

这种行为在过去也有所不同吗?之后是否添加了skipWaiting()和clients.claim()?

service-worker service-worker-events
1个回答
0
投票

默认 - 就像现在一样 - 一般来说更安全,并不会强迫每个人提出各种解决方案。

  1. 用户使用main1.js加载页面,SWv1在1秒后注册,站点现在完全缓存
  2. 用户再次加载页面 - 这次是从SWv1缓存,超快。新的SWv2寄存器在1秒后注册,缓存新资产(main1.js现在是main2.js),通过skipWaiting和clientsClaim获取控制权

现在可能发生两件事:

页面已加载main1.js,浏览器已执行该脚本所说的任何内容。用户已经与页面等进行了交互。页面正在运行main1.js,它希望与SWv1通信,但实际上控制中的SW是SWv2。脚本main1.js可以发送消息并尝试以只有SWv1理解但v2不知道的方式与SW交互。现在页面因为不匹配而中断。

SWv1缓存了站点v1所需的所有资产。因此,如果main1.js在用户与页面交互时延迟加载等等,浏览器将从缓存中获取。由于SWv2已经控制并缓存了它对资产的想法(这些现在是更新的资产),当main1.js试图延迟加载最初由SWv1缓存的东西时,它找不到。此外,因为现在这是一个新部署,资产不再在HTTP服务器上。它本来是由SWv1处理的缓存,但SWv2不知道它。 SWv2知道该文件的较新版本。分页符。

重要的是要了解每个站点/软件组合可能不是这种情况。如果SW脚本中的逻辑非常少,并且main.js没有与sw.js进行太多的通信,则可以构建skipWaiting和clientsClaim不会导致任何问题的组合。您还可以通过以下方式进行编码:如果发生错误,您将向用户显示要刷新的通知。

© www.soinside.com 2019 - 2024. All rights reserved.