我正在考虑使用服务工作线程将我的应用程序离线。我已经通过缓存资源取得了令人满意的结果,但我还必须检查 onfetch 我是否已连接到互联网,如果没有 - 存储请求,并将其同步推送。
我明白, future 的 onsync 会对此有所帮助,但我需要 - 甚至是临时的 - 解决方案。
我试过将请求存储在工作人员的数组中,但它不是持久的 - 在计算机重新启动后不起作用(而 SW 工作并提供离线内容)。
什么是好的方向 - 以某种方式将它像文件一样存储在缓存中?或者使用 IndexedDB/SimpleDB ( Accessing indexedDB in ServiceWorker. Race condition )?
最佳答案
https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics 有一个例子使用 service worker 检测特定类型请求的失败(在本例中,Google Analytics 通过 HTTP GET
执行 ping 操作),并使用 IndexedDB
对失败进行排队。每次服务 worker 启动时都会检查队列,如果请求可以成功“重播”(因为网络现在可用),它就会从队列中删除。虽然无法保证 service worker 何时启动(后台同步事件将在未来提供帮助),但您可以放心地假设,如果有人正在积极使用您的网络应用程序,则 service worker 将自行恢复。
这可以推广到其他类型的请求,例如 HTTP POST
,但有几点需要考虑:
- 确保您的用户知道他们的 HTTP
POST
正在排队并将被重播。由于 HTTPPOST
通常会修改服务器端状态,因此您不希望因 X 小时前的重放请求而导致某些内容发生变化时让用户感到惊讶。 - 根据您调用的服务,HTTP
POST
可能需要有效的Authorization
header 。如果您使用 OAuth 2 进行授权,它可能会使用生命周期有限的访问 token 。在您重放请求时,先前有效的授权 token 可能已过期。 IndexedDB
是对请求进行排队的不错选择,因为它可以灵活地存储任意数据,并且应该可以存储 HTTPPOST
'没有太多工作的 body 。如果您不能使用IndexedDB
(您说不支持使用 Cordova ),那么我能想到的唯一其他选择是尝试使用 Cache Storage API创建一个新的“队列”缓存,将失败的Request
作为键,将空的Response
对象作为值。在服务 worker 启动时,您可以使用keys()
方法在你的“队列”缓存中获取所有Requests
的列表,并且对于每个queuedRequest
,调用fetch(queuedRequest)
来重播它.我以前没有尝试过这种方法,但我认为它应该可行。
关于javascript - 使用服务 worker 存储 REST 请求以同步它们,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29843547/