Progresywne aplikacje internetowe: praca z Workbox

1. Witamy

W tym module weźmiesz witrynę z dotychczasowym mechanizmem Service Worker i przekształcisz ją tak, aby korzystała z Workbox. To drugie szkolenie z serii szkoleń towarzyszących warsztatom dotyczącym progresywnych aplikacji internetowych. Poprzedni codelab to Going Offline. W tej serii jest jeszcze 6 samouczków.

Czego się nauczysz

  • Konwertowanie istniejącego skryptu service worker na Workbox
  • Dodawanie elementu zastępczego offline do PWA

Co warto wiedzieć

  • podstawowy HTML i JavaScript,

Wymagania

2. Pierwsze kroki

Zacznij od sklonowania lub pobrania kodu startowego potrzebnego do ukończenia tego ćwiczenia:

Jeśli klonujesz repozytorium, upewnij się, że jesteś w gałęzi pwa03--workbox. Plik ZIP zawiera też kod tej gałęzi.

Ten kod wymaga Node.js w wersji 14 lub nowszej. Gdy kod będzie dostępny, uruchom npm ci z wiersza poleceń w folderze kodu, aby zainstalować wszystkie potrzebne zależności. Następnie uruchom npm start, aby uruchomić serwer programistyczny dla tego laboratorium.

Plik README.md kodu źródłowego zawiera wyjaśnienie wszystkich rozpowszechnianych plików. Oto najważniejsze pliki, z którymi będziesz pracować w trakcie tego ćwiczenia:

Kluczowe pliki

  • service-worker.js – plik skryptu service worker aplikacji
  • offline.html – offline HTML do użycia, gdy strona jest niedostępna.

3. Przejście na Workbox

Analizując istniejący proces obsługi, można zauważyć, że wstępne buforowanie można podzielić na 2 etapy:

  • Pobieranie do pamięci podręcznej odpowiednich plików podczas instalacji Service Workera
  • Ponownie udostępnij te pliki, stosując strategię Tylko pamięć podręczna.

Plik index.html i trasa / nadal mają sens w przypadku wstępnego buforowania, ponieważ kod HTML tej aplikacji internetowej nie będzie się zbytnio zmieniać. Jednak inne pliki, takie jak CSS i JavaScript, mogą się zmieniać i nie chcemy, aby za każdym razem przechodziły przez cały cykl życia Service Workera. Dodatkowo obecny Service Worker uwzględnia tylko podzbiór naszych plików CSS i JavaScript, a chcemy, aby obejmował wszystkie. Buforowanie tych elementów za pomocą strategii „nieaktualne podczas ponownej weryfikacji” ma więcej sensu, ponieważ zapewnia szybką odpowiedź, którą w razie potrzeby można zaktualizować w tle.

Ponowne sprawdzanie wstępnego buforowania

Podczas migracji do Workboxa nie musimy zachowywać żadnego z dotychczasowych kodów, więc usuń wszystko w service-worker.js. W poprzednim module skonfigurowaliśmy kompilację tego Service Workera, więc możemy tutaj użyć importów ESModule, aby pobrać Workbox z modułów NPM. Zacznijmy od ponownego omówienia wstępnego buforowania. W pliku service-worker.js dodaj ten kod:

import { warmStrategyCache } from 'workbox-recipes';
import { CacheFirst } from 'workbox-strategies';
import { registerRoute } from 'workbox-routing';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
import { ExpirationPlugin } from 'workbox-expiration';

// Set up page cache
const pageCache = new CacheFirst({
  cacheName: 'page-cache',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [0, 200],
    }),
    new ExpirationPlugin({
      maxAgeSeconds: 30 * 24 * 60 * 60,
    }),
  ],
});

warmStrategyCache({
  urls: ['/index.html', '/'],
  strategy: pageCache,
});

registerRoute(({ request }) => request.mode === 'navigate', pageCache);

Wyjaśnienie

Aby skonfigurować wstępne buforowanie dla użytkowników /index.html i /, możesz skorzystać z 5 modułów. Może się to wydawać dużo, ale ten kod jest znacznie bardziej zaawansowany niż poprzedni.

Zaczyna się od skonfigurowania nowej strategii buforowania Cache First, która została wybrana zamiast strategii Cache Only, aby umożliwić dodawanie do pamięci podręcznej innych stron w razie potrzeby. Nadano mu nazwę page-cache. Strategie Workbox mogą korzystać z wielu wtyczek, które mogą wpływać na cykl życia zapisywania i pobierania treści z pamięci podręcznej. W tym przypadku używane są 2 wtyczki: Cacheable Response i Expiration. Dzięki nim w pamięci podręcznej są przechowywane tylko prawidłowe odpowiedzi serwera, a każdy element w pamięci podręcznej jest usuwany po 30 dniach.

Następnie pamięć podręczna strategii jest wypełniana za pomocą /index.html i / przy użyciu przepisu Workbox dotyczącego wypełniania pamięci podręcznej strategii. Spowoduje to dodanie tych elementów do pamięci podręcznej podczas zdarzenia instalacji komponentu Service Worker.

Na koniec rejestrowana jest nowa trasa. Wszystkie żądania nawigacji po stronie będą zarządzane przez tę strategię „Najpierw pamięć podręczna”. Będzie ona pobierać dane z pamięci podręcznej lub sieci, a następnie zapisywać odpowiedź w pamięci podręcznej.

Buforowanie komponentów

Po rozwiązaniu problemu z wstępnym buforowaniem tras czas na ponowne wdrożenie buforowania zasobów witryny, czyli plików CSS i JavaScript. Aby to zrobić, najpierw dodaj StaleWhileRevalidate do importu workbox-strategies, a następnie dodaj ten kod na końcu pliku Service Worker:

// Set up asset cache
registerRoute(
  ({ request }) => ['style', 'script', 'worker'].includes(request.destination),
  new StaleWhileRevalidate({
    cacheName: 'asset-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  }),
);

Wyjaśnienie

Ta ścieżka zaczyna się od określenia, czy typ żądania to styl, skrypt czy instancja robocza, co odpowiada CSS, JavaScript lub Web Workers. Jeśli tak jest, stosuje strategię „nieaktualne podczas ponownej weryfikacji”, która najpierw próbuje wyświetlić dane z pamięci podręcznej, a jeśli nie są dostępne, wraca do sieci. Jednocześnie próbuje zaktualizować wersję w pamięci podręcznej z sieci, jeśli to możliwe. Podobnie jak strategia dotycząca strony, ta strategia będzie buforować tylko dobre odpowiedzi.

4. Dodawanie wartości zastępczej offline

Po przeniesieniu oryginalnego service workera do Workboxa należy wykonać jeszcze jedną czynność, aby zapobiec awarii progresywnej aplikacji internetowej w trybie offline – dodać rezerwę offline.

Wersje offline można ustawić dla wszystkich elementów, które mogą być niedostępne w trybie offline: stron, czcionek, plików CSS, JavaScript, obrazów itp. W przypadku wszystkich progresywnych aplikacji internetowych należy ustawić co najmniej stronę zastępczą, aby użytkownik, który przejdzie do strony nieznajdującej się w pamięci podręcznej, pozostał w kontekście aplikacji.

Przepisy Workbox zawierają przepis na rezerwę offline, który można wykorzystać do tego celu. Aby z niej korzystać, najpierw dodaj offlineFallback do importu workbox-recipes, a potem dodaj ten kod na końcu skryptu service worker:

// Set up offline fallback
offlineFallback({
  pageFallback: '/offline.html',
});

Wyjaśnienie

Przepis na kreację zastępczą offline konfiguruje strategię „Tylko pamięć podręczna”, która jest rozgrzewana za pomocą podanych kreacji zastępczych. Następnie konfiguruje domyślny moduł obsługi błędów Workbox, który przechwytuje wszystkie nieudane żądania routingu (jeśli w pamięci podręcznej nic nie ma i nie można uzyskać dostępu do niczego w sieci), pobiera treść odpowiednich plików z pamięci podręcznej i zwraca ją jako treść, dopóki żądanie nie zostanie zrealizowane.

5. Gratulacje!

Wiesz już, jak używać Workbox do konfigurowania strategii buforowania tras i zapewniania rezerwowych wersji offline dla Twojej progresywnej aplikacji internetowej.

Następny codelab z tej serii to IndexedDB.