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
-
returns
-
-
strategiczne
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
-
returns
Promise<CleanupResult>
-
-
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)[]) => {...}
-
wpisy
(ciąg | PrecacheEntry)[]
Tablica wpisów do buforowania.
-
-
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
.
-
returns
-
-
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
-
returns
Promise<InstallResult>
-
-
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 znaków | Żą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)[]) => {...}
-
wpisy
(ciąg | 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
Opcjonalny PrecacheController
-
-
returns
-
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
-
konstruktor
void
Funkcja
constructor
wygląda tak:(precacheController: PrecacheController, options?: PrecacheRouteOptions) => {...}
-
precacheController
Wystąpienie
PrecacheController
używane do dopasowywania żądań dopasowania i odpowiadania na zdarzenia pobierania. -
Opcje
Opcjonalne PrecacheRouteOptions
-
returns
-
-
catchHandler
Opcjonalny RouteHandlerObject
-
moduł obsługi
-
dopasowanie
-
method
HTTPMethod
-
setCatchHandler
void
Funkcja
setCatchHandler
wygląda tak:(handler: RouteHandler) => {...}
-
moduł obsługi
z funkcją wywołania zwrotnego, która zwraca obiecywanie na odpowiedź
-
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
-
returns
-
-
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) => {...}
-
moduł obsługi
-
Poproś
Prośba
-
event
ExtendableEvent
-
returns
Obietnica<Response>
-
-
_handleFetch
void
Funkcja
_handleFetch
wygląda tak:(request: Request, handler: StrategyHandler) => {...}
-
Poproś
Prośba
-
moduł obsługi
-
returns
Obietnica<Response>
-
-
_handleZainstaluj
void
Funkcja
_handleInstall
wygląda tak:(request: Request, handler: StrategyHandler) => {...}
-
Poproś
Prośba
-
moduł obsługi
-
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ą doevent.respondWith()
.Funkcja
handle
wygląda tak:(options: FetchEvent | HandlerCallbackOptions) => {...}
-
Opcje
FetchEvent | HandlerCallbackOptions
FetchEvent
lub obiekt o właściwościach wymienionych poniżej.
-
returns
Obietnica<Response>
-
-
handleAll
void
Podobnie jak w przypadku
workbox-strategies.Strategy~handle
, ale zamiast zwrócenia po prostu wartościPromise
zwracającej wartośćResponse
zwraca on kropkę[response, done]
, gdzie pierwsza z nich (response
) odpowiada temu, co zwracahandle()
, a druga jest obietnicą, która zostanie rozwiązana po spełnieniu wszelkich obietnic dodanych doevent.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) => {...}
-
Opcje
FetchEvent | HandlerCallbackOptions
FetchEvent
lub obiekt o właściwościach wymienionych poniżej.
-
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
-
Zwroty
-
Adres URL[]
Metody
addPlugins()
workbox-precaching.addPlugins(
plugins: WorkboxPlugin[],
)
Dodaje wtyczki do strategii wstępnego buforowania.
Parametry
-
wtyczki
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
-
Opcje
Opcjonalne PrecacheRouteOptions
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
.
Zwroty
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.
Zwroty
-
ciąg | niezdefiniowany
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 znaków | Żądanie
Klucz (bez parametrów wersji) do wyszukania w pamięci podręcznej.
Zwroty
-
Promise<Response | 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
-
wpisy
(ciąg | PrecacheEntry)[]
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
-
wpisy
(ciąg | PrecacheEntry)[]
Tablica wpisów do buforowania.
-
Opcje
Opcjonalne PrecacheRouteOptions