简体   繁体   English

Angular PWA 哈希文件缓存问题

[英]Angular PWA hash files caching issue

It seems that after a fresh build with azure that my PWA is serving the wrong files似乎在使用 azure 进行全新构建后,我的 PWA 提供了错误的文件

Here is my runtime.*.js after a new build这是我的runtime.*.js新构建后

在此处输入图片说明

as you can see the runtime.*.js is being served as my html document??如您所见, runtime.*.js被用作我的html文档??

then after a hard refresh然后在硬刷新后

在此处输入图片说明

its the correct file...它是正确的文件...

Now I know the service worker caches the bundled files.. but why would it change the file to be a html document after a new azure build??现在我知道 service worker 缓存了捆绑的文件..但是为什么它会在新的 azure 构建后将文件更改为 html 文档?

This is my ngsw-config.json这是我的ngsw-config.json

{
    "index": "/index.html",
    "assetGroups": [
        {
            "name": "app",
            "installMode": "prefetch",
            "resources": {
                "files": ["/favicon.ico", "/index.html", "/manifest.json", "/*.bundle.css", "/*.bundle.js", "/*.chunk.js"]
            }
        },
        {
            "name": "assets",
            "installMode": "lazy",
            "updateMode": "prefetch",
            "resources": {
                "files": ["/assets/**", "/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)"]
            }
        }
    ]
}

Which I have taken from numerous tutorials on how to correctly set up an Angular PWA.我从许多关于如何正确设置 Angular PWA 的教程中获取。

I found this article https://blog.ailon.org/quick-tip-pwa-manifest-and-azure-dd16664a3f43 and it tells you that azure incorrectly serves .json files and to remedy this you can do the following in you web.config我发现这篇文章https://blog.ailon.org/quick-tip-pwa-manifest-and-azure-dd16664a3f43它告诉你 azure 错误地提供了.json文件,为了解决这个问题,你可以在你的web.config执行以下操作web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".json" mimeType="application/json" />
    </staticContent>
    <!-- IIS URL Rewrite for Angular routes -->
    <rewrite>
      <rules>
        <rule name="Angular Routes" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            <add input="{REQUEST_URI}" pattern="^/(api)" negate="true" />
          </conditions>
          <action type="Rewrite" url="/index.html" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

but I am still getting this happen on every new build from azure但我仍然在 azure 的每一个新版本上都会发生这种情况

What am I doing wrong?我究竟做错了什么? Is this the service worker?这是服务人员吗? or is it a problem with azure?还是天蓝色的问题?

This is my azure pipeline这是我的蔚蓝管道

在此处输入图片说明

and this is my release pipeline这是我的发布管道

在此处输入图片说明

How can I solve this issue??我该如何解决这个问题??

Any help would be appreciated!任何帮助,将不胜感激!

In The Begining there was Hash开始时有哈希

A user clicks on home link of your SPA.用户单击您的 SPA 的主页链接。

Angular served pages as site.com/#/home . Angular 提供的页面为site.com/#/home This was fine as a path.这作为一条路径很好。 The part after # is never sent to the server. # 之后的部分永远不会发送到服务器。 Angular router could read from UrL what route and component to serve. Angular 路由器可以从 UrL 读取要服务的路由和组件。

The Change UseHashingStrategy : false更改UseHashingStrategy : false

Then, Angular said we will use site.com/home as the path.然后,Angular 说我们将使用site.com/home作为路径。 Instead of direct request to server for file /home angular intercepts it and serves the component.而不是直接向服务器请求文件/home angular 会拦截它并为组件提供服务。 But for this to work Angular router has to be loaded first.但要使其工作,必须先加载 Angular 路由器。 Otherwise anyone trying to open site.com/home directly would get a 404.否则任何试图直接打开site.com/home都会得到 404。

To fix this Angular suggests fallback to index.html by path rewriting on server.为了解决这个问题,Angular 建议通过在服务器上重写路径来回退到 index.html。 In response for pages ( /home ) a 404 candidate, serve the index file so that router can be loaded first and then serve the correct page.响应页面 ( /home ) 404 候选,提供索引文件,以便路由器可以首先加载,然后提供正确的页面。

The rewrite rules of your webconfig file is doing just that. webconfig 文件的重写规则就是这样做的。 After deployment, when html page requests for runtime*.js file, Azure is serving the index.html file....部署后,当 html 页面请求 runtime*.js 文件时,Azure 正在为 index.html 文件提供服务......

This means Azure could not find the file runtime*.js on server.这意味着 Azure 在服务器上找不到文件 runtime*.js。 You got fall back index.html你得到了回退 index.html

Hope this provides some clue on where to dig next.希望这提供了一些关于下一步挖掘的线索。 My guess is, post deployment when you open index.html it is loaded from cache.我的猜测是,当您打开 index.html 时,部署后它是从缓存加载的。 Having link to old js file.有旧 js 文件的链接。 So, a request for runtime*(old_version)*.js (now deleted after deployment) gives you the fallback file.因此,对 runtime*(old_version)*.js 的请求(部署后现已删除)为您提供后备文件。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM