Меня попросили написать этот пост о довольно незначительном обновлении API кэша сервис-воркера. Я не думал, что это заслуживает отдельной статьи, но после долгих дебатов, которые в конечном итоге свелись к игре в камень-ножницы-бумага, я проиграл, и вот она.
Готовы ли вы услышать об обновлениях реализации API кэша Service Worker в Chrome?
Я не слышу тебя! Я спросил, готовы ли вы услышать об обновлениях реализации Chrome API кэша сервисного работника?
(продолжать чтение можно только в том случае, если вы вскочили на стул и крикнули «ДАААА!». Одновременно с этим делать вид, что размахиваете арканом, необязательно, но приветствуется).
кэш.addAll появился в Chrome 46
Да! Это верно! Кэш! Добавляйте все! Хром 46!
Хорошо, хорошо, если отбросить сарказм, на самом деле это довольно большая проблема, поскольку cache.addAll — это последняя оставшаяся часть полифила «основные» кэша , то есть она больше не нужна.
Вот как работает 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 принимает массив URL-адресов и запросов, извлекает их и добавляет в кеш. Это транзакционный процесс: если какая-либо из операций выборки или записи завершается неудачей, вся операция завершается неудачей, и кеш возвращается в предыдущее состояние. Это особенно полезно для операций установки, подобных описанным выше, где одиночный сбой должен быть общим сбоем.
Приведенный выше пример относится к сервисному работнику, но API кэшей полностью доступен и со страниц.
Firefox уже поддерживает этот API в своей версии для разработчиков , поэтому он будет включен в остальную часть реализации сервис-воркера.
Но подождите, это еще не все, в разработке есть еще улучшения кэша…
cache.matchAll появится в Chrome 47
Это позволяет вам получить несколько совпадений:
caches.open('mysite-static-v1').then(function(cache) {
return cache.matchAll('/');
}).then(function(responses) {
// …
});
Вышеупомянутое получит все, что в mysite-static-v1 соответствует / . Кэш позволяет иметь несколько записей для каждого URL-адреса, если они кэшируются независимо, например, если они имеют разные заголовки Vary .
Firefox уже поддерживает это в своей версии для разработчиков , поэтому он будет включен в остальную часть реализации сервис-воркера.
Параметры запросов к кешу появятся в Chrome… скоро
Вот довольно стандартный обработчик выборки:
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request).then(function(response) {
return response || fetch(event.request);
})
);
});
Если у нас есть / кешированный и мы получаем запрос на / , он будет обработан из кеша. Однако, если мы получим запрос на /?utm_source=blahblahwhatever он не придет из кеша. Вы можете обойти это, игнорируя строку поиска URL-адреса при сопоставлении:
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request, {
ignoreSearch: true
}).then(function(response) {
return response || fetch(event.request);
})
);
});
Теперь /?utm_source=blahblahwhatever будет соответствовать записи / ! Полные варианты:
-
ignoreSearch— игнорировать часть URL-адреса для поиска как в аргументе запроса, так и в кэшированных запросах. -
ignoreMethod— игнорировать метод аргумента запроса, поэтому запрос POST может соответствовать записи GET в кеше. -
ignoreVary— игнорировать заголовок изменения в кэшированных ответах.
Firefox уже поддерживает это в своих… хорошо, вы уже знаете суть. Скажите Бену Келли, какой он молодец, что внедрил все это в Firefox.
Если вы хотите следить за реализацией параметров запроса к кешу в Chrome, посетите crbug.com/426309 .
Увидимся в следующий раз в еще одной захватывающей главе о том, «что мы реализовали в API кэша»!