Do tej pory ta dokumentacja skupiała się na wstępnym przechowywaniu w pamięci podręcznej, często odwołując się do narzędzi do kompilacji generateSW
i injectManifest
. Istnieje wiele powodów, dla których warto uwzględnić w skrypcie service worker logikę pobierania z wyprzedzeniem, ale nie musisz korzystać z pobierania z wyprzedzeniem, aby używać Workboxa.
Być może Twój projekt potrzebuje tylko buforowania w czasie wykonywania lub chcesz w bardziej przejrzysty sposób zintegrować interfejsy API usług roboczych, np. web push. W tym artykule omówiono przypadki, w których nie chcesz używać narzędzi do kompilacji Workbox.
W przypadku korzystania z usług dostawcy usług płatniczych
Pakiety są popularne w środowisku programowania stron internetowych i istnieje duże prawdopodobieństwo, że Twój projekt korzysta z jednego z nich. W takim przypadku nie musisz używać wtyczki do tworzenia pakietów (np. workbox-webpack-plugin
), jeśli niczego nie buforujesz. Twój serwis worker będzie traktowany jako osobny punkt wejścia w aplikacji.
W katalogu głównym katalogu źródłowego projektu utwórz usługę workera i użyj dowolnych modułów Workbox, których wymaga Twoja aplikacja. Oto przykład bez wstępnego buforowania, w którym w osobnych instancjach Cache
skonfigurowano strategie buforowania w przypadku żądań zasobów nawigacji i komponentów z obrazem:
// 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);
Teraz wystarczy określić tego pracownika usługi jako punkt wejścia w wybranym pakietowaniu. Poniżej znajdziesz kilka przykładów na to, jak to zrobić w kilku popularnych narzędziach do tworzenia pakietów.
webpack
webpack akceptuje punkty wejścia w swojej konfiguracji entry
. Pamiętaj o kilku kwestiach, gdy korzystasz z tego podejścia:
- Aby mieć pewność, że usługa workera ma jak najszerszy zasięg, warto umieścić ją w katalogu głównym katalogu wyjściowego.
- Nie chcesz, aby wersje usługi były powiązane z wersjami, ponieważ aktualizacje będą generować nowe hasze, co może spowodować wdrożenie w Twojej witrynie wielu usług.
Aby spełnić powyższe warunki, można przekazać funkcję do output.filename
, która sprawdza, czy bieżący przetwarzany punkt wejścia jest punktem wejścia dla serwisu. W przeciwnym razie pliki z wersjami są zapisywane w normalnych lokalizacjach.
// 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
}
};
podsumowanie
Zbiorcze działają podobnie jak webpack, z tą różnicą, że wiele punktów wejścia jest określonych jako osobne obiekty konfiguracji wyeksportowane w 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')
})
]
}
];
esbuild
esbuild udostępnia prosty interfejs wiersza poleceń:
npx esbuild ./src/sw.js --bundle --minify --outfile=./dist/sw.js
esbuild zastąpi domyślnie zmienną process.env.NODE_ENV wartością „development” (rozwój) lub „production” (produkcja), jeśli włączona jest kompresja.
Bez pakietu za pomocą workbox-sw
Twój projekt może nawet nie używać pakietu. workbox-sw
może wczytać środowisko wykonawcze Workbox za Ciebie z sieci CDN w swoim mechanizmie service worker, ale 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);
Jeśli nie chcesz wczytywać środowiska wykonawczego Workbox z CDN, możesz użyć workbox-sw
z lokalnymi adresami URL.
Podsumowanie
Teraz, gdy wiesz, jak korzystać z Workbox bez wstępnego buforowania, nie musisz już korzystać z konkretnego narzędzia do tworzenia pakietów ani z konkretnego narzędzia do kompilacji. Dzięki temu możesz ręcznie utworzyć skrypt service worker, korzystając tylko z fragmentów kodu pamięci podręcznej Workbox, które Cię interesują.