Używanie skrzynki roboczej bez wstępnego buforowania

Do tej pory dokumentacja ta obejmowała bardzo dużo treści z pamięci podręcznej. Często poruszamy tematy związane z narzędziami do kompilacji generateSW i injectManifest. Chociaż istnieje wiele dobrych powodów, aby włączyć logikę wstępnego buforowania w skrypcie service worker, do korzystania z pamięci podręcznej nie jest konieczne.

Być może Twój projekt wymaga tylko buforowania w czasie działania lub potrzebujesz prostszego sposobu integracji interfejsów API service worker, np. web push. W przypadkach, w których nie chcesz używać narzędzi do tworzenia Workbox, opisujemy to w tym artykule.

Korzystanie z usługi tworzenia pakietów

Bundle są znane w dziedzinie tworzenia stron internetowych, więc prawdopodobnie Twój projekt z nich korzysta. W takim przypadku nie musisz używać wtyczki pakietu SDK (np. workbox-webpack-plugin), jeśli niczego nie blokujesz w pamięci podręcznej. Skrypt service worker będzie traktowane jako oddzielny punkt wejścia w aplikacji.

Uwaga: upewnij się, że wybrany dostawca pakietów obsługuje statyczną składnię import. Jeśli korzystasz z pakietu Webpack, Rollup, Parcel lub esbuild – nie musisz nic robić.

W katalogu głównym katalogu źródłowego projektu utworzysz skrypt service worker i użyjesz dowolnych modułów Workbox, których wymaga Twoja aplikacja. Oto przykład bez wstępnego buforowania, w którym stosowane są strategie buforowania na potrzeby nawigacji i żądań komponentów z obrazem w osobnych instancjach Cache:

// sw.js
import {NetworkFirst, CacheFirst} from 'workbox-strategies';
import {registerRoute, NavigationRoute, Route} from 'workbox-routing';

const navigationRoute = new NavigationRoute(new NetworkFirst({
  cacheName: 'navigations'
}));

const imageAssetRoute = new Route(({request}) => {
  return request.destination === 'image';
}, new CacheFirst({
  cacheName: 'image-assets'
}));

registerRoute(navigationRoute);
registerRoute(imageAssetRoute);

W tym miejscu musisz określić ten skrypt service worker jako punkt wejścia wybranego przez Ciebie pakietu SDK. Poniżej znajdziesz kilka przykładów, jak to zrobić w kilku popularnych narzędziach tego typu.

pakiet internetowy

Pakiet webpack akceptuje punkty wejścia w swojej konfiguracji entry. Stosując tę metodę, pamiętaj o kilku kwestiach:

1. Aby mechanizm Service Worker miał najszerszy możliwy zakres, powinien on trafiać do katalogu głównego katalogu wyjściowego.
2. Nie chcesz, aby mechanizm Service Worker był używany do obsługi wersji, ponieważ jego aktualizacje będą generować nowe hasze, co może spowodować wdrożenie w witrynie wielu mechanizmów Service Worker.

Aby spełnić powyższe warunki, można przekazać funkcję do output.filename, która sprawdza, czy przetwarzany aktualnie punkt wejścia jest punktem wejścia skryptu service worker. W przeciwnym razie pliki z obsługą wersji są zapisywane w normalnych miejscach docelowych.

// webpack.config.js
import process from 'process';

const isProd = process.env.NODE_ENV === 'production';

export default {
  mode: isProd ? 'production' : 'development',
  context: process.cwd(),
  entry: {
    // Service worker entry point:
    sw: './src/sw.js',
    // Application entry point:
    app: './src/index.js'
  },
  output: {
    filename: ({runtime}) => {
      // Check if the current filename is for the service worker:
      if (runtime === 'sw') {
        // Output a service worker in the root of the dist directory
        // Also, ensure the output file name doesn't have a hash in it
        return '[name].js';
      }

      // Otherwise, output files as normal
      return 'js/[name].[contenthash:8].js';
    },
    path: './dist',
    publicPath: '/',
    clean: true
  }
};

Uwaga: w powyższej konfiguracji pakietu internetowego zakłada się, że używasz najnowszej wersji węzła, która obsługuje moduły JavaScript, i w pliku package.json określono "type": "module". W przeciwnym razie musisz użyć semantyki CommonJS.

podsumowanie

Podsumowanie działa podobnie do pakietu internetowego, z tą różnicą, że wiele punktów wejścia określa się jako osobne obiekty konfiguracji wyeksportowane do tablicy:

// rollup.config.js
import { nodeResolve } from '@rollup/plugin-node-resolve';
import replace from '@rollup/plugin-replace';

// Plugins common to both entry points
const plugins = [
  nodeResolve(),
];

export default [
  // Application entry point
  {
    input: './src/index.js',
    output: {
      dir: './dist/js',
      format: 'esm'
    },
    plugins
  },
  // Service worker entry point
  {
    input: './src/sw.js',
    output: {
      file: './dist/sw.js',
      format: 'iife'
    },
    plugins: [
      ...plugins,
      // This @rollup/plugin-replace instance replaces process.env.NODE_ENV
      // statements in the Workbox libraries to match your current environment.
      // This changes whether logging is enabled ('development') or disabled ('production').
      replace({
        'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production')
      })
    ]
  }
];

Ostrzeżenie: w przeciwieństwie do pakietu internetowego o pełnym zakresie nie ma opcji konfiguracji mode, która obsługuje minifikację. Aby to zrobić, musisz zainstalować aplikację rollup-plugin-terser i jej używać.

Esbuild

Narzędzie esbuild ma prosty interfejs wiersza poleceń:

npx esbuild ./src/sw.js --bundle --minify --outfile=./dist/sw.js

esbuild będzie domyślnie zastępować proces.env.NODE_ENV wartością „development” (projektowanie) lub „production” (produkcja), jeśli jest włączona minifikacja.

Bez usługi tworzenia pakietów korzystającej z usługi workbox-sw

Twój projekt może nawet nie korzystać z usługi tworzenia pakietów. workbox-sw może wczytać środowisko wykonawcze Workbox dla Ciebie z sieci CDN w skrypcie service worker bez kroku kompilacji, jeśli zaimportujesz je za pomocą importScripts:

// sw.js

// Imports Workbox from the CDN. Note that "6.2.0" of the URL
// is the version of the Workbox runtime.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

const navigationRoute = new workbox.routing.NavigationRoute(new workbox.strategies.NetworkFirst({
  cacheName: 'navigations'
}));

const imageAssetRoute = new workbox.routing.Route(({request}) => {
  return request.destination === 'image';
}, new workbox.strategies.CacheFirst({
  cacheName: 'image-assets'
}));

workbox.routing.registerRoute(navigationRoute);
workbox.routing.registerRoute(staticAssetRoute);

Uwaga: ten sposób korzystania z dyrektywy workbox-sw jest wygodny, ale wymaga przesłania żądania do serwera WWW innej firmy i powoduje wczytanie kodu, który może pozostać nieużywany. W miarę możliwości korzystaj z usługi tworzenia pakietów, ponieważ pomijają one nieużywane części środowiska wykonawczego, aby przyspieszyć wczytywanie i uniknąć potencjalnie kosztownych żądań z innych domen.

Jeśli perspektywa wczytania środowiska wykonawczego Workbox z sieci CDN nie wydaje się świetna, możesz użyć workbox-sw z lokalnymi adresami URL.

Podsumowanie

Wiesz już, jak korzystać z pola roboczego bez wstępnego buforowania, więc nie jest już powiązane z konkretnym narzędziem do tworzenia pakietów ani tworzenia. Daje to swobodę ręcznego tworzenia skryptu service worker za pomocą tylko tych fragmentów kodu pamięci podręcznej środowiska wykonawczego, które Cię interesują.