服务工作者在响应中缓存的路由 [英] Routes being cached by service worker in react

问题描述

我们正在为我工​​作的公司建立一个新网站，该网站由React使用CRA编写。浏览器推送通知和PWA都是必需的，因此服务人员是必不可少的，但是我相信服务人员应负责一些相当大的缓存问题。

We are in the process of building a new website for the company I work for which is written in React using CRA. Browser push notifications and a PWA are both required so a service worker is essential, however I beleive the service worker is responsible for some fairly major caching issues.

该网站不是但是在生产中，但是我昨天添加了一个新页面（这已经发生过几次了），并且一旦部署到我们的开发环境中，办公室中的任何人都无法访问它-他们只是被重定向到主页（就像路由没有（不存在），直到他们清除了缓存，然后路由就没有问题了。

The website is not yet in production however I added a new page yesterday (and this has happened a few times before) and once deployed to our dev environment nobody in the office was able to access it - they were simply redirected to the homepage (as if the route didn't exist) until they cleared their cache then the route loaded with no issues.

我已经阅读了一些语义版本控制，但是所有文章似乎都使用NPM而不是yarn并在本地进行了版本控制（这对于使用8在这个项目上工作）使用npm版本补丁等。

I've read a little bit on semantic versioning however the articles all seem to use NPM rather than yarn and are versioned locally (which isn't great with a team of 8 working on this project) using npm version patch etc.

我们使用MS Azure作为构建和发布管道，我认为这是设置版本的最佳位置

We are using MS Azure as the build and release pipeline which I assume would be the best place to set versions if this is required.

我的问题是要解决这个问题的步骤是什么，我是否正确地认为版本控制会缓解？

My question is what are the steps to aviod this problem and am I on the correct lines thinking versioning will mitigate?

推荐答案

在这种情况下，语义版本化没有任何意义，您一直在阅读关于NPM发布到NPM的软件包（库，框架）的信息。世界使用。在CRA项目以及大多数其他Web项目中，构建工具会根据其内容命名文件，从而对应用进行版本控制。文件名包括内容的哈希值，并在内容更改时自动进行版本控制，例如。 app.iue9234980s.js变为app.92384oujiuoisdf.js等。

Semantic versioning in this context doesn't make any sense, you've been reading most likely about packages (libraries, frameworks) that are published into NPM for the world to use. In CRA projects, and most other web projects too, versioning of your app happens by the build tools as they name the files based on their contents. The filenames include the hash of the contents and are versioned automatically when contents change, eg. app.iue9234980s.js becomes app.92384oujiuoisdf.js etc.

-

CRA提供的 default Service Worker设置，那么您应该查看src / serviceWorker.js。在该文件的注释中，

If you're using the default Service Worker setup provided by CRA, then you should look at src/serviceWorker.js. In the comments of that file it says

// This lets the app load faster on subsequent visits in production, and gives
// it offline capabilities. However, it also means that developers (and users)
// will only see deployed updates on subsequent visits to a page, after all the
// existing tabs open on the page have been closed, since previously cached
// resources are updated in the background.

这里发生的是，软件和构建过程使用配置为使用预缓存的Workbox SW库政策。根据这项政策，即使有可用的新版本，用户也可以从浏览器的缓存中获取以前缓存的最新版本，然后在后台SW更新缓存，而在另一次访问中，用户则获得较新的版本。当然，这意味着用户可能始终是一个后期版本。

What happens here is that the SW and the build process use Workbox SW library that is configured to use precache policy. In this policy, users get the last version that was previously cached from the browser's cache even if there's a new version available, then in the background SW updates the caches, and on another visit users get the newer version. This of course means that users might always be one version "late".

如果这种行为不是您想要的，则需要更改src / serviceWorker.js和可能是CRA文件中某处的一些配置。例如，您应该在Google上搜索 cra的定制服务人员之类的东西。

If this behaviour is not what you want, then you need to change src/serviceWorker.js and probably some configuration somewhere in CRA files. You should google something like "custom service workers with cra" for examples.

为了更好地掌握正在发生的事情，尤其是在不同配置情况下的正确行为和预期行为，我真的建议（每个人）在以下地方阅读Google的SW软件入门： https： //developers.google.com/web/fundamentals/primers/service-workers
了解SW的基本原理后，检出Workbox库 https://developers.google.com/web/tools/workbox 看看它可以为您的应用程序提供什么。

To better grasp what is happening – and especially what is correct and intended behaviour in differently configured cases – I really recommend (everyone) to read Google's primer on SWs themselves, here: https://developers.google.com/web/fundamentals/primers/service-workers With understanding of the SWs basic principles, it is then probably useful to checkout the Workbox library https://developers.google.com/web/tools/workbox to see what it can offer for your app.

在这里阅读和理解SW的不同方面非常重要-用SW脚踩脚是非常容易的：）

Reading and understanding the different aspects of SW is key here – it is excruciatinly easy to shoot yourself in the foot with SWs :)

这篇关于服务工作者在响应中缓存的路由的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！