Возвращаясь домой на поезде, я был поражен количеством приложений, установленных в моем телефоне, и тем, что у меня есть разные приложения, которые удовлетворяют мои разнородные потребности. Я живу в эпоху Интернета, и я, будучи веб-разработчиком, который очень одержим словом «Интернет» в моем названии, почувствовал некоторое разочарование и сразу же переключился на свой браузер, чтобы перейти на веб-сайт и прочитать блог, который я мирно читал в родном приложении, прежде чем возникло странное чувство. К моему удивлению, прошло 50 секунд, и все, что я вижу, это значок загрузки, постепенно на странице начал появляться какой-то контент. Пока я наблюдал за деревьями за пределами поезда и терпеливо ждал, пока сайт подышит, изображения начали появляться одно за другим, и я чувствую, когда прошло много времени, мой браузер вздохнул после того, как проделал много тяжелой работы, отвечая на вопросы и на сервер, чтобы получить все необходимые ресурсы. Я легко чувствую боль, которую испытывают пользователи при просмотре своего любимого контента в сети, и полностью понимаю желание вернуться к работе с родными приложениями.
Нативные приложения используют возможности операционных систем. Помимо производительности, эти приложения имеют множество невероятных функций, таких как фоновая синхронизация, Offline-First, Push-уведомления. Мы являемся настолько мощным сообществом разработчиков JavaScript, что не можем допустить, чтобы этот опыт преследовал нас, мы не могли изобрести решение - по крайней мере, столь же мощное, как нативные приложения. Похоже, кто-то уже воспринял это всерьез, и вот мы, Service Worker! Service Worker обеспечивает богатый пользовательский интерфейс в автономном режиме, фоновую синхронизацию, беспроблемную обработку ошибок сетевого подключения - без интернета или слабого сигнала, а также push-уведомлений.
Давайте попробуем понять, что такое сервис-воркер
Сервис-воркер, говоря простым языком, - это файл сценария, который выполняется в фоновом режиме, не мешая взаимодействию с пользователем. Service Worker действует как прокси-сервер, который перехватывает сетевые запросы, отправляемые вашим веб-приложением на сервер. В том смысле, что запросы на получение файлов Javascript или CSS, изображения проходят через сервис-воркер на сервер. Service Worker может изменить этот запрос или отправить клиенту собственный ответ. Он использует кеширование в полной мере для кэширования некоторых ресурсов, чтобы последующие запросы этих ресурсов могли быть быстро выполнены с помощью попадания в кеш, вместо того, чтобы полностью возвращаться к серверу для его извлечения (подробнее о кешировании позже). Service Worker работает как система, управляемая событиями.
Событийный
Service worker засыпает, чтобы сэкономить память, когда она не нужна. Таким образом, данные не сохраняются в глобальном состоянии в обработчиках onfetch & onmessage. Чтобы сохранить данные после перезапуска, вы можете использовать IndexedDb API.
Давайте проверим простой пример, демонстрирующий приведенное выше утверждение.
UseCase - мы должны сохранять идентификаторы продуктов на основе того, сколько раз пользователь просматривал конкретный продукт. Мы можем сохранить это в хэш-карте, например:
Поскольку мы не можем полагаться на глобальные переменные, мы будем хранить эту информацию в IndexedDb, чтобы она сохранялась.
Ниже приведен обработчик выборки для перехвата сетевых запросов. Если URL-адрес запроса содержит «product», мы извлекаем существующее количество продуктов, сохраненное по productId, из IndexedDb, увеличиваем productCount на 1 и сохраняем его обратно в IndexedDb.
Связь с другими веб-страницами
Service Worker не может напрямую получить доступ к DOM. Он работает в другом контексте и может общаться с клиентом с помощью postmessages.
UseCase - мы должны отправить сообщение клиенту, когда сервис-воркер будет активирован.
Ниже приведен обработчик события активации сервис-воркера. Service worker отправляет клиенту почтовое сообщение при активации.
Ниже показан прослушиватель клиентского javascript, который прослушивает сообщения и, соответственно, выполняет действие, когда сообщение поступает от сервис-воркера.
Service Worker работает только на сайтах HTTPS
Обработчик событий onfetch Service Worker может изменить или сфабриковать ответ на сетевые запросы. Поэтому очень важно удостовериться, что сервис-воркер не вмешался во время своего путешествия по сети. Кроме того, сервис-воркер должен обслуживаться из того же домена.
Разве это не интересно? Давайте погрузимся в понимание того, как включить сервис-воркера в наше веб-приложение.
1. Регистрация
Чтобы сервис-воркер мог контролировать ваши веб-страницы, мы сначала должны зарегистрировать его в области видимости.
Включите приведенный ниже фрагмент в свой клиентский JavaScript, чтобы зарегистрировать скрипт сервис-воркера ‘service-worker.js’
Некоторые старые браузеры не поддерживают сервис-воркер, поэтому перед его регистрацией мы сначала проверяем, поддерживается ли в браузере API-интерфейс сервис-воркера. Функция регистрации сервисного работника асинхронно загружает скрипт. Если сервис-воркер успешно зарегистрирован, он запускает этап установки.
Когда ваша страница обновляется, регистрационный код сервис-воркера больше не выполняется. Вам не нужно беспокоиться о том, чтобы ваш регистрационный код не запускался несколько раз, об этом позаботится браузер. Service Worker будет зарегистрирован снова только в том случае, если URL-адрес Service Worker отличается или есть разница в байтах между зарегистрированным Service Worker и более новым экземпляром.
Если регистрация не удалась, браузер попытается это сделать при следующей перезагрузке страницы.
Сфера деятельности сервис-воркера
По умолчанию сфера действия сервис-воркера - «/», что означает, что он может перехватывать все сетевые запросы, поступающие от корня. Чтобы зарегистрировать сервис-воркер в другой области или ограничить его возможность перехватывать запросы только с нескольких выбранных страниц, мы можем сделать что-то вроде этого:
Функция регистрации принимает второй необязательный параметр типа object, область видимости которого является одним из ключей. Итак, сфера действия сервис-воркера теперь ограничена «/ products / fashion / {…}». Он не может перехватить запросы, выходящие за рамки его возможностей.
2. Установка
После успешной регистрации сервис-воркера на клиенте все последующие шаги являются частью скрипта сервис-воркера. Здесь вы можете выполнять задачи инициализации, такие как настройка кеша браузера или создание хранилищ объектов в IndexedDB.
Ниже приведен фрагмент для добавления URL-адресов в кеш.
Если все URL-адреса / файлы успешно кэшированы, тогда сервисный работник готов перейти к следующему шагу. Но если даже один из файлов выйдет из строя, он выдает ошибку на этапе установки и будет установлен, при следующем обновлении страницы.
3. Активация
После успешной установки сервис воркер переходит в состояние готовности. Если активного сервис-воркера нет, установленный сервис-воркер переходит в фазу активации. Здесь мы можем управлять старыми ресурсами кеша или очищать устаревшие данные в IndexedDb.
В обработчике события activate мы удаляем все кеши, кроме «products-v2». Даже если этап активации прошел успешно, работник службы по-прежнему не контролирует страницы. Сетевые запросы, сделанные после активации, по-прежнему не будут проходить через обработчик onfetch сервис-воркера. Сервисный работник будет править сайтом, когда сайт не открывается ни на какой другой вкладке, а текущая страница обновляется. Service worker будет прослушивать сетевой запрос на веб-странице только в том случае, если сама страница была получена через Service worker. Это имеет смысл, потому что вполне возможно, что веб-страница использует некоторые ресурсы из кеша, и работник службы изменил ресурсы кеша в событии активации. Если вы по-прежнему хотите, чтобы ваш сервисный работник перехватывал последующие сетевые запросы, вы можете использовать clients.claim(). Он позволяет переопределить это поведение по умолчанию и позволяет сервисному работнику немедленно перехватывать сетевые запросы при успешной активации.
Но если на веб-сайте уже был активный сервисный воркер, новый сервисный воркер не войдет в фазу активации, если этот старый сервисный работник не будет зарегистрирован.
Если вы хотите избавиться от активного сервис-воркера и позволить новому взять на себя ответственность, вы можете сделать что-то вроде этого:
self.skipWaiting () предотвращает состояние ожидания и активирует сервис-воркер сразу после его установки.
Давайте попробуем понять терминологию, которую мы использовали в нашем коде
Что с ключевым словом ‘self’?
self используется в качестве справочника сервис-воркера, как мы используем «this» для ссылки на любой экземпляр в JavaScript.
А как насчет event.waitUntil()? Почему мы вообще его используем?
К настоящему времени мы знаем, что сервис-воркер работает как система, управляемая событиями. Он переходит в неактивное состояние, когда в нем нет необходимости. До тех пор, пока код, написанный при установке, или событие активации не будет выполнено, мы хотим, чтобы наш сервисный работник был активен и выполнял свою работу. event.waitUntil () делает именно это. Service Worker остается активным до тех пор, пока не будет выполнен код внутри event.waitUntil.
Как мне узнать, контролируется ли моя веб-страница каким-либо сервисным работником?
Я создал приложение Pokemon, чтобы продемонстрировать возможности сервис-воркера. Вы можете проверить это здесь"
