Изучение кеша сервис-воркеров, обновление, апгрейд [I]

Следить за тенденцией PWA может быть немного сложно, давайте реализуем простого сервис-воркера и разберемся с основами включения функций обновления / обновления в проекте.

Что мы строим?

В этом примере мы создаем страницу, которая кэширует активы и отображает кнопку обновления в случае обнаружения нового сервис-воркера. Простая обработка битов данных в существующем файле сервис-воркера может заставить наши браузеры рассматривать его как новый (в нашем случае я просто изменил номер версии).

Используя Chrome DevTools, мы видим, что в кеш-хранилище доступна более новая версия. Наш новый сервис-воркер в настоящее время находится в состоянии ожидания или установлен (подробнее о состояниях ПО).

Пользователю отображается кнопка обновления, которая переключает управление на ожидающего работника службы и удаляет старые кеши.

Давайте прямо в это дело!

index.html - простая страница, состоящая из:

• 2 изображения (cat1.jpg, cat2.jpg)
• Текст титров
• Кнопка обновления (по умолчанию скрыта)

sw.js - наш служебный рабочий файл, здесь происходит волшебство!

Он заботится о:

• Установка сервис-воркера
• Кеширование файлов, указанных в массиве appCash
• Загрузка запросов из кеша или их получение обычно
• Переключение состояния sw и удаление старых кешей путем прослушивания сообщений от клиента (script.js)

script.js - Здесь много чего происходит, давайте снова разберемся на точки, но последовательно.

Клиент :

• Регистрирует сервис-воркер
• Прослушивает событие «updatefound», которое запускается, когда браузер обнаруживает более новый SW-файл.
• Копирует ссылку ожидающего / установленного сервис-воркера в переменную «newSW».
• Включает кнопку обновления, когда новый сервис-воркер завершает установку (кэширование ресурсов)
• Отправляет сообщения в sw.js с помощью функции upSW (), вызываемой при нажатии кнопки
• Перезагружает страницу при смене текущего сервис-воркера.

Получите весь проект здесь -

Использованная литература -