Этот вопрос меня тоже часто смущает, поэтому я постараюсь привести несколько примеров и, надеюсь, прояснить для нас обоих.
Пример 1
Допустим, у вас есть версия 1 вашего сайта с работником службы версии 1:
- Ваш сайт запрашивает фотографии кошек
- Ваш обслуживающий работник перехватывает изображения кошек и заменяет их изображениями собак
Затем вы обновляете своего сервисного работника до v2:
- теперь ваш SW перехватывает изображения кошек и заменяет их изображениями кроликов
Если пользователь с установленным ПО v1 сейчас посещает сайт, а работник сервиса v2 настроен на немедленную активацию, начинается гонка:
- Если ПО v2 извлекается, устанавливается и активируется до того, как будет сделан запрос изображения (может быть, его запрашивают при пользовательском вводе или загружается с отложенной загрузкой или что-то медленное), тогда изображение кошки будет заменено зайчиком
- Но если изображение кошки запрашивается до активации ПО v2, изображение будет заменено собакой
Так что, если бы это было что-то более значимое, чем просто изображения животных, то ваш сайт мог бы сломаться для некоторых пользователей в зависимости от времени.
Этот пример от Джейка Арчибальда (я, наверное, его вырезал), и у него есть демо-приложение, связанное с ним, но я не думаю, что сама статья объясняет риски конкретно. Но идея в том, что
"skipWaiting () означает, что ваш новый работник службы, скорее всего,
управляющие страницы, которые были загружены с более старой версией. Это означает
некоторые выборки вашей страницы будут обработаны вашим старым сервисом
работник, но ваш новый работник службы будет обрабатывать последующие
выбирает. "
Где skipWaiting совпадает с немедленной активацией. Чтобы продолжить идею последующих загрузок страницы ...
Пример 2
Опять, скажем, у вас есть версия 1 вашего сайта с работником службы версии 1:
- Ваши конечные точки сервера возвращают JSON для динамического содержимого
- Служащий обслуживает файл index.html со стратегией «сначала кеш»
- Работник сервиса обрабатывает шаблоны на вашем сайте (поэтому, когда какой-то JSON извлекается из конечной точки, работник сервиса делает HTML из этого и возвращает готовый для вставки HTML на страницу - вот пример что )
Но тогда вы решаете просто сделать шаблон самой страницы, потому что это имеет больше смысла для браузеров, которые не поддерживают сервисный работник. Вы реализуете версию 2 своего сайта и версию 2 своего сервисного работника:
- Сервисный работник теперь возвращает JSON напрямую (без шаблонов в ПО)
- Страница ожидает JSON и отображает там шаблоны.
Теперь, если пользователь обновляет свое приложение после того, как вы выпустили v2 (при условии, что они посетили v1):
- их активный работник службы v1 будет обслуживать ваш v1 index.html из кэша, который ожидает, что HTML будет возвращен по запросам.
- Служащий v2 собирается установить
Если работник службы v2 активируется прямо сейчас, у них будет страница index.html v1, которая ожидает шаблонный HTML от запросов, но ваш новый работник службы v2 будет возвращать JSON.
Я могу ошибаться, так что я открыт для других предложений, но я подумал, что мне это удастся. Надеюсь, это поможет?