tworzenie buforowania w polu roboczym

Jedną z funkcji skryptów service worker jest zapisywanie zbioru plików w pamięci podręcznej podczas instalacji. Jest to często określane jako „wstępowanie”, ponieważ buforujesz treść przed użyciem skryptu service worker.

Głównym powodem jest to, że deweloperzy mają kontrolę nad pamięcią podręczną, co oznacza, że mogą określić, kiedy i jak długo plik jest przechowywany w pamięci podręcznej, a także wyświetlać go w przeglądarce bez połączenia z siecią, co pozwala tworzyć aplikacje internetowe działające w trybie offline.

Workbox upraszcza zapisywanie w pamięci podręcznej, ponieważ upraszcza interfejs API i dba o wydajne pobieranie zasobów.

Jak działa wywoływanie pól roboczych

Przy pierwszym wczytywaniu aplikacji internetowej workbox-precaching sprawdza wszystkie zasoby, które chcesz pobrać, usuwa duplikaty i podłącza odpowiednie zdarzenia skryptu service worker, by pobrać i przechowywać zasoby. Adresy URL, które już zawierają informacje o wersjach (np. hasz treści), są używane jako klucze pamięci podręcznej bez wprowadzania żadnych dalszych modyfikacji. W przypadku adresów URL, które nie zawierają informacji o obsłudze wersji, do klucza pamięci podręcznej dołączany jest dodatkowy parametr zapytania URL, który reprezentuje hasz treści generowany przez Workbox podczas kompilacji.

Wszystko to robi workbox-precaching podczas zdarzenia install skryptu service worker.

Gdy użytkownik ponownie odwiedza Twoją aplikację internetową i pojawia się nowy skrypt service worker z innymi zasobami wstępnie zapisywanymi w pamięci podręcznej, workbox-precaching przyjrzy się nowej liście i w zależności od ich weryfikacji określi, które zasoby są całkowicie nowe, a które wymagają aktualizacji. Wszystkie nowe zasoby lub aktualizacje wersji zostaną dodane do pamięci podręcznej podczas zdarzenia install nowego skryptu service worker.

Ten nowy skrypt service worker nie będzie używany do odpowiadania na żądania, dopóki nie zostanie wywołane jego zdarzenie activate. To w ramach zdarzenia activate workbox-precaching sprawdzi, czy w pamięci podręcznej nie ma zasobów, których nie ma już na liście bieżących adresów URL, i usunie je z pamięci podręcznej.

workbox-precaching wykona te czynności za każdym razem, gdy mechanizm Service Worker zostanie zainstalowany i aktywowany, upewniając się, że użytkownik ma najnowsze zasoby i pobiera tylko zmienione pliki.

Wyświetlanie odpowiedzi w pamięci podręcznej

Wywołanie precacheAndRoute() lub addRoute() spowoduje utworzenie trasy, która będzie odpowiadać żądaniam adresów URL wstępnie zapisanych w pamięci podręcznej.

Strategia odpowiedzi stosowana na tej trasie jest priorytetowa w pamięci podręcznej: odpowiedź z pamięci podręcznej zostanie użyta, chyba że odpowiedź z pamięci podręcznej nie istnieje (z powodu nieoczekiwanego błędu). W takim przypadku zamiast tego zostanie użyta odpowiedź sieci.

Kolejność wywołań funkcji precacheAndRoute() lub addRoute() jest ważna. Zwykle warto wywołać ją odpowiednio wcześnie w pliku skryptu service worker, zanim zarejestrujesz dodatkowe trasy w registerRoute(). Jeśli najpierw wywołano funkcję registerRoute(), a trasa pasuje do żądania przychodzącego, odpowiedź będzie stosowana niezależnie od strategii zdefiniowanej w tej dodatkowej trasie, a nie w przypadku strategii opartej na pamięci podręcznej używanej przez workbox-precaching.

Objaśnienie listy pamięci podręcznej

workbox-precaching wymaga tablicy obiektów z właściwością url i revision. Ta tablica jest czasami nazywana plikiem manifestu precache:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute([
  {url: '/index.html', revision: '383676'},
  {url: '/styles/app.0c9a31.css', revision: null},
  {url: '/scripts/app.0d5770.js', revision: null},
  // ... other entries ...
]);

Ta lista odwołuje się do zestawu adresów URL, z których każdy ma własną informację o „zmianach”.

W przypadku drugiego i trzeciego obiektu w przykładzie powyżej właściwość revision jest ustawiona na null. Dzieje się tak, ponieważ informacje o poprawianiu znajdziesz w adresie URL, co jest zwykle sprawdzoną metodą w przypadku zasobów statycznych.

Pierwszy obiekt (/index.html) bezpośrednio ustawia właściwość wersji, czyli automatycznie wygenerowany skrót zawartości pliku. W przeciwieństwie do zasobów JavaScript i CSS pliki HTML zasadniczo nie mogą zawierać informacji o wersji w adresach URL. W przeciwnym razie linki do tych plików w internecie nie będą działać po każdej zmianie treści strony.

Dzięki przekazaniu właściwości wersji do precacheAndRoute() Workbox będzie wiedzieć, że plik się zmienił, i odpowiednio go zaktualizuje.

Workbox zawiera narzędzia ułatwiające generowanie tej listy:

  • workbox-build: to pakiet węzłów, którego można używać w zadaniu gulp lub jako skryptu uruchamiania npm.
  • workbox-webpack-plugin: użytkownicy pakietu internetowego mogą używać tej wtyczki.
  • workbox-cli: nasz interfejs wiersza poleceń może też posłużyć do wygenerowania listy zasobów i dodania ich do skryptu service worker.

Żądania przychodzące dotyczące plików w pamięci podręcznej

Jedną z rzeczy, które workbox-precaching robi od razu, jest manipulowanie przychodzącymi żądaniami sieciowymi w celu dopasowania plików w pamięci podręcznej. Znajdziesz w nim typowe praktyki stosowane w internecie.

Na przykład żądanie / może zwykle zostać spełnione przez plik pod adresem /index.html.

Poniżej znajdziesz listę manipulacji, które workbox-precaching wykonuje domyślnie, wraz z informacjami, jak możesz te manipulacje zmienić.

Ignoruj parametry adresu URL

Żądania z parametrami wyszukiwania można modyfikować, aby usunąć określone wartości lub wszystkie.

Domyślnie parametry wyszukiwania zaczynające się od utm_ lub ściśle dopasowane do fbclid są usuwane. Oznacza to, że żądanie /about.html?utm_campaign=abcd zostanie wypełnione wartością /about.html w pamięci podręcznej.

Za pomocą funkcji ignoreURLParametersMatching możesz zignorować inny zestaw parametrów wyszukiwania:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    // Ignore all URL parameters.
    ignoreURLParametersMatching: [/.*/],
  }
);

Indeks katalogu

Żądania, których nazwa kończy się cyframi /, są domyślnie porównywane z wpisami z końcówką index.html. Oznacza to, że przychodzące żądanie / może być automatycznie obsługiwane za pomocą zapisanego w pamięci podręcznej wpisu /index.html.

Możesz ją zmienić lub całkowicie wyłączyć, ustawiając directoryIndex:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    directoryIndex: null,
  }
);

Wyczyść adresy URL

Jeśli żądanie nie pasuje do pamięci podręcznej, na końcu dodajemy .html, aby umożliwić obsługę „czystych” adresów URL (czyli „ładnych” adresów). Oznacza to, że żądanie takie jak /about będzie obsługiwane przez wpis dla /about.html w pamięci podręcznej.

Możesz wyłączyć tę funkcję, ustawiając cleanUrls:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute([{url: '/about.html', revision: 'b79cd4'}], {
  cleanUrls: false,
});

Niestandardowe manipulacje

Jeśli chcesz zdefiniować niestandardowe dopasowania w przypadku żądań przychodzących do zasobów wstępnie zapisanych w pamięci podręcznej, możesz to zrobić za pomocą opcji urlManipulation. Powinno to być wywołanie zwrotne, które zwraca tablicę możliwych dopasowań.

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    urlManipulation: ({url}) => {
      // Your logic goes here...
      return [alteredUrlOption1, alteredUrlOption2];
    },
  }
);

Zaawansowane użycie

Bezpośrednie korzystanie z PrecacheController

Domyślnie workbox-precaching skonfiguruje za Ciebie detektory install i activate. Dla programistów zaznajomionych z mechanizmami Service Worker może to nie być korzystne, jeśli potrzebujesz większej kontroli.

Zamiast korzystać z eksportu domyślnego, możesz użyć metody PrecacheController bezpośrednio, aby dodać elementy do pamięci podręcznej, określić, kiedy zasoby zostaną zainstalowane i kiedy należy je wyczyścić.

import {PrecacheController} from 'workbox-precaching';

const precacheController = new PrecacheController();
precacheController.addToCacheList([
  {url: '/styles/example-1.abcd.css', revision: null},
  {url: '/styles/example-2.1234.css', revision: null},
  {url: '/scripts/example-1.abcd.js', revision: null},
  {url: '/scripts/example-2.1234.js', revision: null},
]);

precacheController.addToCacheList([{
  url: '/index.html',
  revision: 'abcd',
}, {
  url: '/about.html',
  revision: '1234',
}]);

self.addEventListener('install', (event) => {
  // Passing in event is required in Workbox v6+
  event.waitUntil(precacheController.install(event));
});

self.addEventListener('activate', (event) => {
  // Passing in event is required in Workbox v6+
  event.waitUntil(precacheController.activate(event));
});

self.addEventListener('fetch', (event) => {
  const cacheKey = precacheController.getCacheKeyForURL(event.request.url);
  event.respondWith(caches.match(cacheKey).then(...));
});

Bezpośrednie odczytywanie zasobów wstępnie zapisanych w pamięci podręcznej

Czasem może być konieczne bezpośrednie odczytanie zasobu zapisanego w pamięci podręcznej, poza kontekstem routingu, które workbox-precaching może wykonać automatycznie. Możesz na przykład zapisać w pamięci podręcznej częściowe szablony HTML, które następnie trzeba pobrać i wykorzystać przy tworzeniu pełnej odpowiedzi.

Ogólnie obiekty Response przechowywane w pamięci podręcznej można uzyskać za pomocą interfejsu Cache Storage API, ale jest jeden problem: klucz pamięci podręcznej adresu URL, którego należy użyć podczas wywoływania cache.match(), może zawierać parametr obsługi wersji, który workbox-precaching automatycznie tworzy i utrzymuje.

Aby uzyskać prawidłowy klucz pamięci podręcznej, możesz wywołać metodę getCacheKeyForURL(), przekazując pierwotny adres URL, a następnie użyć wyniku do wykonania w odpowiedniej pamięci podręcznej cache.match().

import {cacheNames} from 'workbox-core';
import {getCacheKeyForURL} from 'workbox-precaching';

const cache = await caches.open(cacheNames.precache);
const response = await cache.match(getCacheKeyForURL('/precached-file.html'));

Jeśli potrzebujesz tylko obiektu Response w pamięci podręcznej, możesz wywołać metodę matchPrecache(), która automatycznie użyje odpowiedniego klucza pamięci podręcznej i przeszuka odpowiednią pamięć:

import {matchPrecache} from 'workbox-precaching';

const response = await matchPrecache('/precached-file.html');

Czyszczenie starych pamięci podręcznej

Większość wersji Workbox ma ten sam format do przechowywania wstępnie zapisanych danych, a pamięci podręcznej utworzone przez starsze wersje tej usługi mogą być normalnie używane w nowszych wersjach. Niekiedy zdarza się jednak, że zmiany w pamięci podręcznej wymagają od obecnych użytkowników ponownego pobrania wszystkiego, a dane wcześniej przechowywane w pamięci podręcznej stają się nieaktualne. (taka zmiana zaszła pomiędzy wersjami 3 i 4 Workspace).

Te nieaktualne dane nie powinny zakłócać normalnego działania, ale wpływają na ogólne wykorzystanie limitu miejsca na dane, a użytkownik może łatwiej je usunąć. Aby to zrobić, dodaj cleanupOutdatedCaches() do skryptu service worker lub ustaw cleanupOutdatedCaches: true, jeśli generujesz skrypt service worker za pomocą jednego z narzędzi do kompilacji dostępnych w Workbox.

Korzystanie z integralności zasobu podrzędnego

Niektórzy deweloperzy mogą chcieć dodać dodatkowe gwarancje oferowane przez mechanizm integralności zasobów podrzędnych podczas pobierania z sieci adresów URL z pamięci podręcznej.

Do każdego wpisu w pliku manifestu precache można dodać dodatkową, opcjonalną właściwość o nazwie integrity. Jeśli zostanie podana, zostanie użyta jako wartość integrity podczas tworzenia obiektu Request służącego do wypełniania pamięci podręcznej. W razie niezgodności proces wstępnego buforowania się nie uda.

Określanie, które wpisy w pliku manifestu wstępnego buforowania powinny mieć właściwości integrity, i ustalanie odpowiednich wartości do wykorzystania, nie należy do zakresu narzędzi do tworzenia w Workbox. Zamiast tego deweloperzy, którzy chcą włączyć tę funkcję, powinni zmodyfikować plik manifestu precached generowany przez Workbox, aby samodzielnie dodać odpowiednie informacje. Opcja manifestTransform w konfiguracji narzędzi do tworzenia w Workbox może pomóc w tych kwestiach:

const ssri = require('ssri');

const integrityManifestTransform = (originalManifest, compilation) => {
  const warnings = [];
  const manifest = originalManifest.map(entry => {
    // If some criteria match:
    if (entry.url.startsWith('...')) {
      // This has to be a synchronous function call, for example:
      // compilation will be set when using workbox-webpack-plugin.
      // When using workbox-build directly, you can read the file's
      // contents from disk using, e.g., the fs module.
      const asset = compilation.getAsset(entry.url);
      entry.integrity = ssri.fromData(asset.source.source()).toString();

      // Push a message to warnings if needed.
    }
    return entry;
  });

  return {warnings, manifest};
};

// Then add manifestTransform: [integrityManifestTransform]
// to your Workbox build configuration.

Typy

CleanupResult

Właściwości

  • deletedCacheRequests

    string[]

InstallResult

Właściwości

  • notUpdatedURLs

    string[]

  • updatedURLs

    string[]

PrecacheController

Efektywne zapisywanie zasobów w pamięci podręcznej.

Właściwości

  • konstruktor

    void

    Utwórz nowy kontroler PrecacheController.

    Funkcja constructor wygląda tak:

    (options?: PrecacheControllerOptions)=> {...}

    • Opcje

      PrecacheControllerOptions opcjonalnie

  • strategia

    Strategia

  • aktywuj

    void

    Usuwa zasoby, których nie ma już w bieżącym pliku manifestu Precache. Wywołaj tę metodę ze zdarzenia aktywacji skryptu service worker.

    Uwaga: ta metoda wywołuje za Ciebie metodę event.waitUntil(), więc nie musisz samodzielnie wywoływać jej w modułach obsługi zdarzeń.

    Funkcja activate wygląda tak:

    (event: ExtendableEvent)=> {...}

    • event

      ExtendableEvent

  • addToCacheList

    void

    Ta metoda dodaje elementy do listy z pamięci podręcznej, usuwa duplikaty i zapewnia poprawność informacji.

    Funkcja addToCacheList wygląda tak:

    (entries: (string|PrecacheEntry)[])=> {...}

  • createHandlerBoundToURL

    void

    Zwraca funkcję, która wyszukuje url w pamięci podręcznej (biorąc informacje o wersji konta) i zwraca odpowiednią wartość Response.

    Funkcja createHandlerBoundToURL wygląda tak:

    (url: string)=> {...}

    • URL

      string,

      Adres URL w pamięci podręcznej, który będzie służyć do wyszukiwania Response.

  • getCacheKeyForURL

    void

    Zwraca klucz pamięci podręcznej używany do przechowywania podanego adresu URL. Jeśli adres URL ma wyłączoną wersję, np. „/index.html”, kluczem pamięci podręcznej będzie pierwotny URL z dołączonym do niego parametrem wyszukiwania.

    Funkcja getCacheKeyForURL wygląda tak:

    (url: string)=> {...}

    • URL

      string,

      Adres URL, którego klucz pamięci podręcznej chcesz wyszukać.

    • returns

      string,

      Adres URL z wersją, który odpowiada kluczowi pamięci podręcznej pierwotnego adresu URL, lub niezdefiniowany, jeśli adres nie został wstępnie zapisany w pamięci podręcznej.

  • getCachedURLs

    void

    Zwraca listę wszystkich adresów URL, które zostały zapisane w pamięci podręcznej przez bieżący skrypt service worker.

    Funkcja getCachedURLs wygląda tak:

    ()=> {...}

    • returns

      string[]

      Adresy URL w pamięci podręcznej.

  • getIntegrityForCacheKey

    void

    Funkcja getIntegrityForCacheKey wygląda tak:

    (cacheKey: string)=> {...}

    • cacheKey

      string,

    • returns

      string,

      Integralność zasobu podrzędnego powiązana z kluczem pamięci podręcznej lub niezdefiniowana, jeśli nie jest ustawiona.

  • getURLsToCacheKeys

    void

    Zwraca mapowanie wstępnie zapisanego adresu URL na odpowiedni klucz pamięci podręcznej z uwzględnieniem informacji o wersji adresu URL.

    Funkcja getURLsToCacheKeys wygląda tak:

    ()=> {...}

    • returns

      Mapa<string>

      Mapowanie klucza z adresu URL do pamięci podręcznej.

  • Zainstaluj

    void

    Wczytuje w pamięci podręcznej nowe i zaktualizowane zasoby. Wywołaj tę metodę ze zdarzenia instalacji skryptu service worker.

    Uwaga: ta metoda wywołuje za Ciebie metodę event.waitUntil(), więc nie musisz samodzielnie wywoływać jej w modułach obsługi zdarzeń.

    Funkcja install wygląda tak:

    (event: ExtendableEvent)=> {...}

    • event

      ExtendableEvent

  • matchPrecache

    void

    Zastępuje on cache.match(), występując w tych kwestiach:

    • Wie, jaka jest nazwa pamięci podręcznej, i sprawdza ją tylko w tej pamięci.
    • Umożliwia przekazanie „oryginalnego” adresu URL bez parametrów obsługi wersji, a automatyczne wyszukiwanie prawidłowego klucza pamięci podręcznej dla aktualnie aktywnej wersji tego adresu URL.

    Np. matchPrecache('index.html') znajdzie prawidłową odpowiedź z pamięci podręcznej w przypadku obecnie aktywnego skryptu service worker, nawet jeśli rzeczywisty klucz pamięci podręcznej to '/index.html?__WB_REVISION__=1234abcd'.

    Funkcja matchPrecache wygląda tak:

    (request: string|Request)=> {...}

    • Poproś

      ciąg|Żądanie

      Klucz (bez parametrów wersji) do wyszukania w pamięci podręcznej.

    • returns

      Obietnica<Response>

  • zapisywanie w pamięci podręcznej

    void

    Dodaje elementy do listy wstępnie zapisanej pamięci podręcznej, usuwając wszelkie duplikaty i zapisuje pliki w pamięci podręcznej po zainstalowaniu przez skrypt service worker.

    Tę metodę można wywołać wiele razy.

    Funkcja precache wygląda tak:

    (entries: (string|PrecacheEntry)[])=> {...}

PrecacheEntry

Właściwości

  • integralność

    ciąg znaków opcjonalny

  • wersja

    ciąg znaków opcjonalny

  • URL

    string,

PrecacheFallbackPlugin

PrecacheFallbackPlugin umożliwia określenie odpowiedzi „zastępczej offline”, która ma być używana, gdy dana strategia nie może wygenerować odpowiedzi.

Odbywa się to przez przechwytywanie wywołania zwrotnego wtyczki handlerDidError i zwracanie odpowiedzi z pamięci podręcznej, automatycznie uwzględniając oczekiwany parametr wersji.

Jeśli nie przekażesz instancji PrecacheController do konstruktora, używana będzie instancja domyślna. Ogólnie rzecz biorąc, większość programistów będzie korzystać z ustawień domyślnych.

Właściwości

  • konstruktor

    void

    Konstruuje nową wtyczkę PrecacheFallbackPlugin z powiązanym zastępczym adresem URL.

    Funkcja constructor wygląda tak:

    (config: object)=> {...}

    • konfiguracja

      obiekt

      • fallbackURL

        string,

        Adres URL z pamięci podręcznej, który ma służyć jako kreacja zastępcza, jeśli powiązana strategia nie może wygenerować odpowiedzi.

      • precacheController

PrecacheRoute

Podklasa workbox-routing.Route, która wybiera wystąpienie workbox-precaching.PrecacheController i używa jej do dopasowywania żądań przychodzących i obsługi pobierania odpowiedzi z pamięci podręcznej.

Właściwości

PrecacheRouteOptions

Właściwości

  • cleanURLs

    wartość logiczna opcjonalna

  • directoryIndex

    ciąg znaków opcjonalny

  • ignoreURLParametersMatching

    RegExp[] opcjonalny

  • urlManipulation

    urlManipulation opcjonalne

PrecacheStrategy

Implementacja workbox-strategies.Strategy zaprojektowana do działania z workbox-precaching.PrecacheController do pobierania i pamięci podręcznej zasobów.

Uwaga: instancja tej klasy jest tworzona automatycznie podczas tworzenia obiektu PrecacheController. Zwykle nie musisz tworzyć go samodzielnie.

Właściwości

  • konstruktor

    void

    Funkcja constructor wygląda tak:

    (options?: PrecacheStrategyOptions)=> {...}

    • Opcje

      PrecacheStrategyOptions opcjonalne

  • cacheName

    string,

  • fetchOptions

    RequestInit opcjonalnie

  • matchOptions

    CacheQueryOptions opcjonalnie

  • wtyczki
  • copyRedirectedCacheableResponsesPlugin
  • defaultPrecacheCacheabilityPlugin
  • _awaitComplete

    void

    Funkcja _awaitComplete wygląda tak:

    (responseDone: Promise<Response>,handler: StrategyHandler,request: Request,event: ExtendableEvent)=> {...}

    • responseDone

      Obietnica<Response>

    • moduł obsługi
    • Poproś

      Prośba

    • event

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

    Funkcja _getResponse wygląda tak:

    (handler: StrategyHandler,request: Request,event: ExtendableEvent)=> {...}

    • returns

      Obietnica<Response>

  • _handleFetch

    void

    Funkcja _handleFetch wygląda tak:

    (request: Request,handler: StrategyHandler)=> {...}

    • returns

      Obietnica<Response>

  • _handleZainstaluj

    void

    Funkcja _handleInstall wygląda tak:

    (request: Request,handler: StrategyHandler)=> {...}

    • returns

      Obietnica<Response>

  • nick

    void

    Wykonuje strategię żądań i zwraca kod Promise, który zostanie rozwiązany za pomocą Response, wywołując wszystkie odpowiednie wywołania zwrotne wtyczki.

    Jeśli instancja strategii jest zarejestrowana w Workbox workbox-routing.Route, ta metoda jest wywoływana automatycznie po dopasowaniu trasy.

    Tej metody można też używać w samodzielnym nasłuchującym FetchEvent, przekazując ją do event.respondWith().

    Funkcja handle wygląda tak:

    (options: FetchEvent|HandlerCallbackOptions)=> {...}

    • returns

      Obietnica<Response>

  • handleAll

    void

    Podobnie jak w przypadku workbox-strategies.Strategy~handle, ale zamiast zwrócenia po prostu wartości Promise zwracającej wartość Response zwraca on kropkę [response, done], gdzie pierwsza z nich (response) odpowiada temu, co zwraca handle(), a druga jest obietnicą, która zostanie rozwiązana po spełnieniu wszelkich obietnic dodanych do event.waitUntil() w ramach realizacji strategii.

    Możesz poczekać na obietnicę done, aby mieć pewność, że każda dodatkowa praca wykonywana przez strategię (zwykle odpowiedzi w pamięci podręcznej) zakończy się pomyślnie.

    Funkcja handleAll wygląda tak:

    (options: FetchEvent|HandlerCallbackOptions)=> {...}

    • returns

      [Promise<Response>,Promise<void>]

      Kropka [response,Done], której można użyć do określenia, kiedy odpowiedź zostanie zakończona, a także o wykonaniu całej pracy przez moduł.

urlManipulation()

workbox-precaching.urlManipulation(
  { url }: object,
)

Typ

funkcja

Parametry

  • { url }

    obiekt

    • URL

      URL

Akcje powrotne

  • Adres URL[]

Metody

addPlugins()

workbox-precaching.addPlugins(
  plugins: WorkboxPlugin[],
)

Dodaje wtyczki do strategii wstępnego buforowania.

Parametry

addRoute()

workbox-precaching.addRoute(
  options?: PrecacheRouteOptions,
)

Dodaj do skryptu service worker odbiornik fetch, który będzie odpowiadać na [żądania sieciowe]https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Custom_responses_to_requests z zasobami w pamięci podręcznej.

Na żądania dotyczące zasobów, które nie są wstępnie zapisane w pamięci podręcznej, dyrektywa FetchEvent nie odpowiada, dzięki czemu zdarzenie jest przekazywane do innych odbiorników fetch.

Parametry

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

Dodaje detektor zdarzeń activate, który usuwa niezgodne pamięci podręczne utworzone przez starsze wersje Workbox.

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

Funkcja pomocnicza, która wywołuje funkcję PrecacheController#createHandlerBoundToURL w domyślnej instancji PrecacheController.

Jeśli tworzysz własną instancję PrecacheController, wywołaj w niej PrecacheController#createHandlerBoundToURL, zamiast używać tej funkcji.

Parametry

  • URL

    string,

    Adres URL w pamięci podręcznej, który będzie służyć do wyszukiwania Response.

Akcje powrotne

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

Pobiera adres URL i zwraca odpowiedni adres URL, którego można użyć do wyszukania wpisu w pamięci podręcznej.

Jeśli zostanie podany względny URL, jako podstawa zostanie użyta lokalizacja pliku skryptu service worker.

W przypadku wpisów w pamięci podręcznej bez informacji o wersji klucz pamięci podręcznej jest taki sam jak pierwotny adres URL.

W przypadku wpisów w pamięci podręcznej z informacjami o wersji kluczem pamięci podręcznej będzie pierwotny adres URL z dodatkowym parametrem zapytania służącym do śledzenia informacji o wersji.

Parametry

  • URL

    string,

    Adres URL, którego klucz pamięci podręcznej ma zostać wyszukany.

Akcje powrotne

  • ciąg|nieokreślony

    Klucz pamięci podręcznej odpowiadający temu adresowi URL.

matchPrecache()

workbox-precaching.matchPrecache(
  request: string|Request,
)

Funkcja pomocnicza, która wywołuje funkcję PrecacheController#matchPrecache w domyślnej instancji PrecacheController.

Jeśli tworzysz własną instancję PrecacheController, wywołaj w niej PrecacheController#matchPrecache, zamiast używać tej funkcji.

Parametry

  • Poproś

    ciąg|Żądanie

    Klucz (bez parametrów wersji) do wyszukania w pamięci podręcznej.

Akcje powrotne

  • Obietnica<Odpowiedź|undefined>

precache()

workbox-precaching.precache(
  entries: (string|PrecacheEntry)[],
)

Dodaje elementy do listy wstępnie zapisanej pamięci podręcznej, usuwając wszelkie duplikaty i zapisuje pliki w pamięci podręcznej po zainstalowaniu przez skrypt service worker.

Tę metodę można wywołać wiele razy.

Uwaga: ta metoda nie wyświetla żadnych plików z pamięci podręcznej. Służy tylko do wstępnego buforowania plików. Aby odpowiedzieć na żądanie sieci, wywołaj metodę workbox-precaching.addRoute.

Jeśli masz 1 tablicę plików do wczytania w pamięci podręcznej, możesz wywołać po prostu workbox-precaching.precacheAndRoute.

Parametry

precacheAndRoute()

workbox-precaching.precacheAndRoute(
  entries: (string|PrecacheEntry)[],
  options?: PrecacheRouteOptions,
)

Ta metoda spowoduje dodanie wpisów do listy pamięci podręcznej i dodanie trasy, która odpowiada za pobieranie zdarzeń.

Jest to wygodny sposób, który wywołuje workbox-precaching.precache i workbox-precaching.addRoute w jednym wywołaniu.

Parametry