preface

This paper describes the access and use of workbox-webpack-plugin based on project optimization access to Service Worker (later abbreviated as SW) tool. Basic content of Service Worker will not be explained in detail. If you want to know more, please refer to: Developer.mozilla.org/zh-CN/docs/… Developers.google.com/web/fundame…

The basic concept

The Service concept of the Worker

instructions

  1. A Service Worker is a script that the browser runs in the background independently of the web page, opening the door to functionality that does not require web pages or user interaction.
  2. It essentially acts as a proxy server between Web applications, browsers, and the network (when available). This API is designed to create an effective offline experience that intercepts network requests and takes appropriate action to update resources from the server based on whether the network is available. It also provides a portal to push notifications and access background synchronization apis.

[Note] : The Service worker runs in the worker context, so it cannot access the DOM. It runs in a different thread than the main JavaScript thread that drives the application, so it doesn’t block. It is designed to be fully asynchronous, and synchronization apis such as XHR and localStorage (en-us) cannot be used in service workers

A prerequisite for

1. Browser support

  • Service workers are supported by Chrome, Firefox, and Opera. Microsoft Edge now supports it publicly. You can check the support for all browsers on is Serviceworker Ready

2, HTTPS

  • During development, you can use the Service Worker through localhost, but if you want to deploy the Service Worker on the site, you need to set HTTPS on the server.

  • With service worker threads, you can hijack connections, orchestrate, and filter responses. It’s a very powerful tool. You may use these features in good faith, but middlemen can use them for bad purposes. To avoid this, register the Service Worker only on the page served over HTTPS, so we know that the Service Worker received by the browser has not been tampered with throughout the network transfer.

The life cycle

  1. When using methodsnavigator.serviceWorker.registerWhen a new ServiceWorker is registered, the browser downloads the JS script and parses it. The ServiceWorker is ininstallingState. If the installation is successful, enterinstalledState, otherwise enterredundantState.
  2. Enter ServiceWorker after it is successfully installedinstalledState. At this point the Service is completeThe installation process, waiting for entryThe activation process.
  3. ServiceWoker Is successfully installedactivatingState.
  4. activatedThe ServiceWorker now controls the page and can listen for functional events, such as fetch and push events. By default, ServiceWorker can only control pages that load after it has been successfully activated
  5. redundantThe state is the final state of the ServiceWorker

Workbox – webpack – plugin concept

Workbox – webpack – plugin is introduced

Workbox provides two Webpack plug-ins: one generates the complete Service Worker for you, and another generates a list of assets to be pre-cached and injected into the Service Worker file.

The plugin is implemented in the workbox-webpack-plugin module as two classes, named GenerateSW and InjectManifest. Refer to DEVELOPERS SW for detailed introduction;

Workbox – webpack – plugin access

1, install,

npm i --save  workbox-webpack-plugin
Copy the code
2. Use in WebpackGenerateSW

【 Attention 】 :

  1. SwDest must be in the same directory as index. HTML, because the serviceWork file can only match subdirectory files in this directory.
  2. The clientsClaim Service Worker takes control of the page immediately after it is activated
  3. SkipWaiting Forces the Service Worker in the wait to be activated
  4. RuntimeCaching Property configuration:
    1. UrlPattern Indicates the matching regular rule
    2. How handler attributes are cached

      1. ‘CacheFirst’ : local cache takes precedence

      2. ‘CacheOnly’ : Only cache is supported

      3. ‘NetworkFirst’ : NetworkFirst

      4. ‘NetworkOnly’ : supports the network

      5. ‘StaleWhileRevalidate’ : The network is parallel to the cache

5. Buildconfig. VERSION is a timestamp that represents the VERSION generated by sw, which is also used to obtain sw files in subsequent business code

3. Register service workers

【 Attention 】 :

  1. The official environment accesses a domain name starting with GAems, but the interface accesses a domain name starting with DEO. However, the Serviceworker must cache in the same domain. Therefore, ensure that the same domain is the same
  2. Since Serviceworker is a persistent cache, the code/interface data will change if it is used during development, but the page will still fetch previously cached data, so to avoid this event, only register when NODE_ENV === ‘production’
  3. If the URL contains the SW parameter, serviceWorker is not required for debugging
  4. If the ServicerWorker exists but is not triggered, you need to deregister the ServiceWorker from the browser
  5. Once the registration is successful, the window.SERVICE_WORKER If this parameter is set to true, registration is successful

4. Effect of successful access

You can see that static and other resources accessed are preferentially obtained from the ServiceWorker

Sw. Js js implementation

The previous implementation is automatically generated by webpack-plugin wrapped in Workbox, so how is its JS implemented?

Refer to the file

Workbox 3: Service Worker can be so simple: fed.taobao.org/blog/taofed…

The Service Worker API: developer.mozilla.org/zh-CN/docs/…

Introduce the Service Worker developers.google.com/web/fundame…