NB * Это не абсолютный вводный курс для начинающих обслуживающего персонала, предполагается наличие некоторых базовых знаний.
Вы когда-нибудь хотели контролировать сетевые запросы, кэшировать эти запросы и предоставлять автономный доступ к кэшированному контенту? Что ж, мы собираемся превратить веб-сайт портфолио в прогрессивное веб-приложение, также известное как PWA, с помощью сервис-воркеров. Но хм !! что за черт обслуживающий работник 🤔️.
Согласно developers.google.com, сервис-воркер - это разновидность веб-воркера. По сути, это файл JavaScript, который запускается отдельно от основного потока браузера, перехватывает сетевые запросы, кэширует или извлекает ресурсы из кеша и доставляет push-сообщения.
Хватит говорить, мне нужен код. Ага, давай сделаем это.
- Регистрация сервис-воркера.
Во-первых, мы проверяем, поддерживает ли браузер сервис-воркеров, и если да, то регистрируем сервис после срабатывания события загрузки. Функция регистрации сервисного работника принимает в качестве аргумента путь к файлу сервисного работника и возвращает обещание, которое мы назвали регистрацией, и вы можете создать console.log объекта регистрации, чтобы увидеть его свойства, такие как область, которая определяет, из какого пути сервис-воркер перехватывает запросы. Область по умолчанию - это местоположение сервис-воркера, и она распространяется на все каталоги ниже него.
2. Установка сервис-воркера
В нашем случае мы хотим использовать подход кэширования контента, когда пользователь впервые посещает сайт, а затем при повторном посещении пользователю будет предоставлен контент из кеша. В нашем служебном файле мы создаем две переменные, одна из которых содержит имя нашего кеша, а другая - массив ресурсов для хранения в кеше.
А теперь самое интересное 😎️. Сделаем собственно установку сервис-воркера.
В сервис-воркер мы добавляем прослушиватель для события установки. Это первое событие в жизненном цикле сервис-воркера. Событие установки запускается, как только сервис-воркер запускается, и запускается только один раз для каждого сервис-воркера. Если вы измените сценарий сервисного воркера, браузер считает его другим сервисным воркером и получит собственное событие установки.
Событие установки имеет метод waitUntil (), а обещание, которое вы передаете этому методу, позволяет браузеру узнать, завершилось ли событие установки и было ли оно успешным. В нашем waitUntil (), мы передаем функцию done, которая открывает кеш и добавляет все наши ресурсы в кеш.
3. Обслуживание пользователей с кэшированным содержанием.
Теперь, когда мы добавили наши ресурсы в кеш, мы собираемся отвечать на запросы пользователей этими ресурсами из кеша, и они смогут получить доступ к веб-сайту даже в автономном режиме. Что !!! ! я сказал офлайн ?? Да, офлайн😎️, круто, правда? Посмотрим, как это сделать.
Обслуживание ресурсов из кеша может быть немного сложным, и вам нужно выбрать стратегию, которую вы хотите использовать, в зависимости от ваших требований, например, вы можете использовать стратегию сначала сеть, в которой вы обслуживаете кэшированный контент только тогда, когда пользователь находится в автономном режиме, но в нашем случае мы используем простую стратегию «сначала кэш», когда мы всегда начинаем с обслуживания ресурсов из кеша, а затем возвращаемся в сеть, если ресурс отсутствует в нашем кеше.
Событие выборки запускается при запросе ресурса. В событии выборки у нас есть доступ к объекту request, и мы хотим ответить ответом, где event.respondWith () приходит метод. В функции repondWith мы передаем функцию getResponse, которая возвращает ответ. Перейдем к функции getResponse.
getResponse принимает запрос в качестве аргумента и возвращает объект ответа. Сначала мы передаем запрос методу caches.match (), и если в кеше есть ресурс, который соответствует переданным запросам, мы получаем ответ с ресурсом и Walaaa !!!! 🤠️ у нас есть удалось ответить на запрос, не попав в сеть. Ответ похож на обычный ответ, который вы получаете при использовании выборки, поэтому вы даже можете проверить статус ответа. Мы с вами оба знаем, что ответы не всегда хороши, а иногда они даже недоступны, поэтому нам нужно разобраться с этими случаями.
Если вы дойдете до блока try-catch, это означает, что ресурс, который вы ищете, не был в кеше, поэтому мы делаем фактический сетевой запрос ресурса, и если по какой-то причине вы не получаете ответ, вы даете пользователю настраиваемая автономная страница (была кэширована в событии установки).
Если запрос был успешным, первое и самое важное - это клонировать ответ, поскольку вы не можете использовать ответ дважды, потому что это поток, поэтому мы клонируем его вместо этого, а затем работаем с клоном. После клонирования ответа мы добавляем клон в кеш, чтобы, если у нас снова будет этот запрос, нам не нужно будет делать сетевой запрос, а мы получим его из кеша. После добавления клона в кеш мы возвращаем ответ из сети пользователю.
4. Очистка
Теперь, когда мы предоставили автономный доступ к нашему веб-сайту, нам нужен способ очистки старых ресурсов из кеша на случай, если есть обновленный контент.
Очистка выполняется после срабатывания события активации, и это событие срабатывает, когда старый сервисный воркер ушел, то есть когда есть новая версия сервисного воркера [попробуйте изменить cacheName], чтобы вызвать это событие. Событие активации также имеет метод waitUntil, который ожидает разрешения переданного обещания. В функции done мы сначала получаем массив всех имен [ключей] кешей, которые есть в нашем кеше, и перебираем этот массив. Если имя кеша из кеша отсутствует в нашем массиве новых кешей (то есть не в cacheNames), этот кеш считается устаревшим, и мы удаляем его из кеша.
Я надеюсь, что эта статья помогла вам, и если да, вы можете оставить отзыв, комментируя статью. Не торопитесь, мы сделаем веб-установку доступной вместе, вы можете увидеть это на josemukorivo.co.zw, хотя работа еще не завершена.
