使用Workbox创建PWA应用

前言

最近公司项目迭代逐渐放缓，下班时间逐渐变早，所以本着渐进增加的理念，在下班后，将公司项目进行了一下PWA改造

为何要改造成PWA

用户需求。我们的用户有许多电脑小白，不想记网址，又不会使用浏览器的收藏功能。以前使用的同类软件都有桌面版，有一种觉得桌面版比网页版可靠，使用简单的错觉，曾多次在钉钉售后群里反映，如何将网页保存至桌面，方便他下次直接在桌面打开
PWA是渐进式的，如果用户的浏览器不支持ServiceWorker等构建PWA所需的API，并不会对其造成使用上的影响，并且通过埋点平台获知，我们用户Chrome浏览器数量占到80%左右
离线缓存，可安装，可拦截fetch等功能，对我个人有一定的吸引力，希望学习使用

开始改造

为了快速改造成PWA, 我这里选择使用了谷歌推出的PWA工具库workbox, 并且结合webpack创建serviceWorker文件

安装依赖

npm install --save-dev workbox-webpack-plugin
npm install --save workbox-core workbox-routing workbox-strategies workbox-precaching workbox-expiration workbox-cacheable-response

workbox-webpack-plugin里提供了两种插件，GenerateSW以及InjectManifest。

GenerateSW

GenerateSW插件可以通过配置直接编译生成对应的serviceWorker文件，不需要我们直接编写serviceWorker文件。使用方式大致如下:

import { InjectManifest } from 'workbox-webpack-plugin';

new GenerateSW({
    skipWaiting: true,
    clientsClaim: true,
    mode: 'development',
    runtimeCaching: [
      {
        urlPattern: /^https?\:\/\/.+?\.alicdn.com\/.+$/,
        handler: 'StaleWhileRevalidate'
      },
    ],
});

通过GenerateSW编译生成serviceWorker文件虽然简单，但不够灵活，所以实际上我使用了另一个InjectManifestPlugin插件

InjectManifest

InjectManifest主要做了两件事

将webpack编译生成的资源文件清单，以变量self.__WB_MANIFEST的形式注入到我们提供的serviceWorker模板文件中
编译我们提供的模板文件，生成目标serviceWorker文件

使用方式大致如下:

const { InjectManifest } = require('workbox-webpack-plugin');
new InjectManifest({
    swSrc: path.resolve('src/sw.js'),
    swDest: path.resolve(BUILD_DEST, 'sw.js'),
}),

编写serviceWorker模板文件

预缓存静态资源

预缓存会在serviceWork激活后，立即请求并缓存所有预缓存清单中的文件, 之后下载请求同一资源时，会使用缓存优先策略，优先使用已经预缓存的资源

workbox.precaching.precacheAndRoute(self.__WB_MANIFEST);

路由请求缓存

使用NavigationRoute来缓存html文件

registerRoute(
  new NavigationRoute(
    new NetworkFirst({
      cacheName: 'navigation-cache',
      plugins: [
        new CacheableResponsePlugin({
          statuses: [200]
        }),
        new ExpirationPlugin({
          maxEntries: 300,
          maxAgeSeconds: 7 * 24 * 60 * 60,
        }),
      ],
    }),
  ),
);

缓存本地静态资源文件

registerRoute(
  /\.(css|js|png|jpg|jpeg|svg|webp)$/,
  new CacheFirst({
    cacheName: 'static-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [200]
      }),
      new ExpirationPlugin({
        maxEntries: 300,
        maxAgeSeconds: 7 * 24 * 60 * 60,
      }),
    ],
  }),
);

缓存cdn中的静态资源文件

registerRoute(
  /^https?\:\/\/.*?\.alicdn.com\/.+?\.(css|js|png|jpg|jpeg|svg|gif|webp)$/,
  new CacheFirst({
    cacheName: 'alicdn-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [200]
      }),
      new ExpirationPlugin({
        maxEntries: 300,
        maxAgeSeconds: 7 * 24 * 60 * 60,
      }),
    ],
  }),
);

这里有一个需要注意的点，alicdn静态资源与我司网页域名不是同域名，存在跨域，当请求静态资源的时候，会返回不透明响应(opaque response); 当我们使用Cache-First策略缓存不透明响应时,workbox会提示我们不要使用这个策略来缓存不透明响应，因为不透明响应对JavaScript来说是一个黑盒，无法获取到正确的status code, headers, body, 所以我们缓存中的资源是不可靠的;并且当我们缓存不透明响应时，缓存所占有的空间远大于实际资源的大小，容易造成DOMException: Quota exceeded. 所以需要处理下不透明响应的缓存

不透明响应变成透明响应

既然不透明响应会造成问题，那只要把不透明响应变成透明响应，那就应该没问题了。
经过查看，我发现alicdn的响应头会返回access-control-allow-origin: *, 后端是支持cors跨域资源共享的。既然如此，只要当我们请求静态资源的时候，让请求走cors应该就可以了。于是，我尝试在其中一个img标签中，启用cors

不透明响应成功变成透明响应。但如果给所有