Ik ben gevraagd om dit bericht te schrijven over een vrij kleine update van de cache-API voor servicemedewerkers. Ik vond niet dat het een eigen artikel verdiende, maar na een lang debat dat uiteindelijk neerkwam op een spelletje steen-papier-schaar, heb ik verloren, dus hier is het.
Bent u klaar om te horen over de updates van Chrome's implementatie van de service worker cache API?
Ik kan je niet horen! Ik zei: ben je klaar om te horen over de updates van Chrome's implementatie van de service worker cache API?
(je mag alleen verder lezen als je op je stoel bent gesprongen en “YEAHHH!” hebt geroepen. Tegelijkertijd doen alsof je met een lasso zwaait is optioneel, maar wordt aangemoedigd).
cache.addAll is gearriveerd in Chrome 46
Ja! Dat is juist! Cache! Punt alles toevoegen! Chroom 46!
Oké, afgezien van het sarcasme, dit is eigenlijk een behoorlijk groot probleem, aangezien cache.addAll het laatst overgebleven deel is van de cache “essentials” polyfill , wat betekent dat het niet langer nodig is.
Zo werkt cache.addAll :
// when the browser sees this SW for the first time
self.addEventListener('install', function(event) {
// wait until the following promise resolves
event.waitUntil(
// open/create a cache named 'mysite-static-v1'
caches.open('mysite-static-v1').then(function(cache) {
// fetch and add this stuff to it
return cache.addAll([
'/',
'/css/styles.css',
'/js/script.js',
'/imgs/cat-falls-over.gif'
]);
})
);
});
addAll neemt een reeks URL's en verzoeken, haalt ze op en voegt ze toe aan de cache. Dit is transactioneel: als een van de ophaal- of schrijfbewerkingen mislukt, mislukt de hele bewerking en wordt de cache teruggezet naar de vorige staat. Dit is met name handig voor installatiebewerkingen zoals hierboven, waarbij een enkele fout een algehele fout zou moeten zijn.
Het bovenstaande voorbeeld is van een servicemedewerker, maar de cache-API is ook volledig toegankelijk vanaf pagina's.
Firefox ondersteunt deze API al in hun ontwikkelaarseditie , dus deze zal bij de rest van hun servicewerknemersimplementatie terechtkomen.
Maar wacht, dat is nog niet alles, er zitten nog meer cacheverbeteringen in de pijplijn...
cache.matchAll komt naar Chrome 47
Hierdoor kun je meerdere matches krijgen:
caches.open('mysite-static-v1').then(function(cache) {
return cache.matchAll('/');
}).then(function(responses) {
// …
});
Het bovenstaande krijgt alles in mysite-static-v1 dat overeenkomt met / . Met de cache kunt u meerdere vermeldingen per URL hebben als deze onafhankelijk in de cache kunnen worden opgeslagen, bijvoorbeeld als ze verschillende Vary headers hebben.
Firefox ondersteunt dit al in hun ontwikkelaarseditie , dus het zal bij de rest van hun servicewerkimplementatie terechtkomen.
Cache-queryopties komen binnenkort naar Chrome
Hier is een vrij standaard ophaalhandler:
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request).then(function(response) {
return response || fetch(event.request);
})
);
});
Als we / in de cache hebben opgeslagen en we krijgen een verzoek voor / , wordt deze vanuit de cache geserveerd. Als we echter een verzoek krijgen voor /?utm_source=blahblahwhatever , komt dat niet uit de cache. U kunt dit omzeilen door de url-zoekreeks te negeren tijdens het matchen:
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request, {
ignoreSearch: true
}).then(function(response) {
return response || fetch(event.request);
})
);
});
Nu wordt /?utm_source=blahblahwhatever gekoppeld aan de invoer voor / ! De volledige opties zijn:
-
ignoreSearch- negeer het zoekgedeelte van de URL in zowel het verzoekargument als in de cache opgeslagen verzoeken -
ignoreMethod- negeer de methode van het verzoekargument, zodat een POST-verzoek kan overeenkomen met een GET-vermelding in de cache -
ignoreVary- negeer de vari-header in in de cache opgeslagen antwoorden
Firefox ondersteunt dit al in hun... oké, je kent de oefening inmiddels. Vertel Ben Kelly hoe geweldig hij is om dit allemaal in Firefox te krijgen.
Als je de Chrome-implementatie van de cachequeryopties wilt volgen, ga dan naar crbug.com/426309 .
Tot de volgende keer voor nog een spannend hoofdstuk over “wat we in de cache-API hebben geïmplementeerd”!