В качестве фона я бы рекомендовал прочитать Жизненный цикл сервисного работника. . Он написан с точки зрения общего обслуживающего работника, но эти моменты применимы и к обслуживающему персоналу на базе Workbox.
Эти концепции также объясняются более подробно с точки зрения использования create-react-app в этом обращении внимания при ленивой загрузке Обсуждение и микросайт.
Реализация Workbox
Workbox использует обработчик событий install для кэширования новых или обновленных записей в манифесте предварительного кеширования (добавляя параметр запроса __WB_REVISION__ к URL-адресам записей, когда это необходимо, чтобы избежать перезаписи существующих записей с другими версиями), и он использует обработчик событий activate для удаления ранее кэшированные записи, которые больше не указаны в манифесте предварительного кеширования.
Если skipWaiting истинно, то обработчик activate, отвечающий за очистку устаревших URL-адресов из кеша, будет выполняться сразу после установки обновленного сервис-воркера.
В таких обстоятельствах есть ли причина не просто установить skipWaiting в значение true?
Использование skipWaiting сопряжено с небольшими рисками и из соображений безопасности мы отключили его по умолчанию в Workbox. (Он был включен по умолчанию в старых, sw-precache -генерированных сервис-воркерах.)
Предположим, что ваш HTML-код загружается в первую очередь в кеш (как правило, это лучшая практика), а затем через некоторое время после этой загрузки обнаруживается обновление сервис-воркера.
Риск 1: отложенная загрузка содержимого с отпечатками пальцев
Современные веб-приложения часто сочетают в себе два метода: асинхронную отложенную загрузку ресурсов только при необходимости (например, переключение на новое представление в одностраничном приложении) и добавление отпечатков пальцев (хэшей) для уникальной идентификации URL-адресов на основе содержимого, которое они содержат.
Традиционно либо сам HTML (или некоторый JavaScript, содержащий информацию о маршруте, которая также загружается на ранней стадии жизненного цикла страницы), содержит ссылку на текущий список URL-адресов, которые необходимо загружать с отложенной загрузкой.
Предположим, что версия вашего веб-приложения, которая была изначально загружена (до того, как произошло обновление Service worker), считает, что URL /view-one.abcd1234.js необходимо загрузить, чтобы отобразить /view-one. Но тем временем вы развернули обновление для своего кода, и /view-one.abcd1234.js был заменен на вашем сервере и в вашем манифесте предварительного кеширования на /view-one.7890abcd.js.
Если skipWaiting истинно, то /view-one.abcd1234.js будет очищено из кешей как часть события activate. Скорее всего, вы уже удалили его со своего сервера в рамках развертывания. Так что этот запрос не удастся.
Если skipWaiting ложно, то /view-one.abcd1234.js будет оставаться доступным в ваших кэшах до тех пор, пока все открытые клиенты сервис-воркера не будут закрыты. Обычно это то, что вам нужно.
Примечание. Хотя использование сервис-воркера может повысить вероятность столкновения с этим классом проблем, это проблема для всех веб-приложений, которые лениво загружают URL-адреса с поддержкой версий. У вас всегда должна быть предусмотрена обработка ошибок, чтобы обнаруживать сбои при отложенной загрузке и пытаться исправить, например, принудительно перезагрузив страницу. Если у вас есть такая логика восстановления и вас устраивает этот UX, вы все равно можете включить skipWaiting.
Риск 2: отложенная загрузка несовместимой логики
Это похоже на первый риск, но применяется, когда в ваших URL-адресах нет хеш-отпечатков. Если вы развернете обновление для своего HTML и соответствующее обновление для одного из ваших представлений, существующие клиенты могут прекратить отложенную загрузку версии /view-one.js, которая не соответствует структуре HTML, полученной из кеша.
Если skipWaiting ложно, то это вряд ли произойдет, поскольку /view-one.js, загруженный из кеша, должен соответствовать структуре HTML, загруженной из того же кеша. Вот почему это более безопасный вариант по умолчанию.
Примечание. Как и раньше, этот риск не является уникальным для сервис-воркеров - любое веб-приложение, которое динамически загружает неверсированные URL-адреса, может в конечном итоге загрузить несовместимую логику после недавнего развертывания.
так что же делает clientsClaim?
clientsClaim гарантирует, что все неконтролируемые клиенты (то есть страницы), находящиеся в области действия, будут контролироваться сервисным воркером сразу после его активации. Если вы не включите его, они не будут контролироваться до следующей навигации.
Обычно это безопаснее, чем skipWaiting, и может быть полезно, если вы хотите, чтобы сервисный работник начал заполнять кеши времени выполнения раньше, чем позже.
Я отсылаю вас к разделу в Документ о жизненном цикле Service Worker для получения дополнительной информации.
person
Jeff Posnick
schedule
06.08.2018
