Почему self.skipWaiting () и self.clients.claim () не являются поведением по умолчанию для сервисных работников - PullRequest
Новая
       12

Почему self.skipWaiting () и self.clients.claim () не являются поведением по умолчанию для сервисных работников

0 голосов
/ 27 апреля 2019

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

При установке нового работника сервиса, пока установлен старый, работнику сервиса придется ждать активации.С помощью self.skipWaiting () и self.clients.claim () можно полностью активировать работника службы и управлять страницами.Я не понимаю, почему это не поведение по умолчанию.Основная причина, которую я могу найти, заключается в том, чтобы сохранить согласованность кода и данных (https://redfin.engineering/service-workers-break-the-browsers-refresh-button-by-default-here-s-why-56f9417694). При некотором базовом понимании жизненного цикла, не должно ли быть возможным сохранить согласованность кода и данных, когда работник службы обновляет или я пропускаючто-то? Есть ли какие-то дополнительные причины?

Также было ли это поведение в прошлом другим? Были ли добавлены skipWaiting () и clients.claim () впоследствии?

1 Ответ

0 голосов
/ 27 апреля 2019

По умолчанию - как сейчас - в целом безопаснее и не заставляет всех придумывать всевозможные решения.

  1. Пользователь загружает страницу с main1.js, SWv1 регистрируется через 1 секунду, сайт теперь полностью кэширован
  2. Пользователь снова загружает страницу - на этот раз из кеша SWv1, очень быстро. Новый SWv2 регистрируется через 1 секунду, кэширует новые активы (main1.js теперь main2.js), получает управление через skipWaiting и clientsClaim

Теперь могут произойти две вещи:

Страница загрузилась с main1.js, и браузер выполнил все, что сказал этот скрипт. Пользователь взаимодействовал со страницей и т. Д. На странице запущен файл main1.js, который ожидает общения с SWv1, но на самом деле SW в контроле - SWv2. Сценарий main1.js может отправлять сообщения и пытаться взаимодействовать с программным обеспечением так, чтобы это понимал только SWv1, но v2 не имеет никакого представления об этом. Теперь страница разрывается из-за несоответствия.

SWv1 кэшировал все ресурсы, которые нужны сайту v1. Таким образом, если main1.js должен что-то лениво загружать и т. Д., Когда пользователь взаимодействует со страницей, браузер получит это из кэша. Поскольку SWv2 взял на себя управление и кэшировал свое представление об активах (теперь это более новые активы), когда main1.js пытается выполнить отложенную загрузку чего-то, что первоначально кэшировалось SWv1, это не найдено. Кроме того, поскольку теперь это новое развертывание, актив больше не находится на HTTP-сервере. Это было бы в кэш-памяти, обработанной SWv1, но SWv2 не знает об этом. SWv2 знает о более новой версии этого файла. Разрывы страниц.

Важно понимать, что это может быть не так для каждой комбинации сайт / ПО. Если у вас очень мало логики в скрипте SW и main.js не слишком связывается с sw.js, можно создать комбинацию, в которой skipWaiting и clientsClaim не вызывают никаких проблем. Вы также можете кодировать таким образом, чтобы в случае возникновения ошибки вы показывали пользователю уведомление для обновления.

...