Введение в сервисных работников

Сервисные работники обеспечивают некоторую техническую основу для функций, которые обычно требуют нативного приложения.
Сервисный работник — это код JavaScript, который ваш браузер запускает в фоновом режиме, отдельно от веб-страницы, открывая двери для функций, которые не нужны. не нужна веб-страница или взаимодействие с пользователем.
Чтобы установить сервис-воркер для своего сайта, вам необходимо зарегистрировать его, что вы делаете в JavaScript своей страницы. Регистрация сервис-воркера приведет к тому, что браузер запустит этап установки сервис-воркера в фоновом режиме.

Предпосылки

- Требуется поддержка браузера
Можно проверить здесь.
- Требуется HTTPS
В процессе разработки вы сможете используйте сервис-воркер через локальный хост, но для его развертывания на сайте вам потребуется настроить HTTPS на вашем сервере.

Зарегистрировать сервисного работника

Сообщите браузеру, где находится ваш файл JavaScript сервисного работника:

if (‘serviceWorker’ in navigator) {
 window.addEventListener(‘load’, function() {
 navigator.serviceWorker.register(‘/sw.js’).then(function(registration) {
 // Registration succeded
 console.log(‘ServiceWorker registration successful with scope: ‘, registration.scope);
 }, function(err) {
 // Registration failed
 console.log(‘ServiceWorker registration failed: ‘, err);
 });
 });
}

Вы можете без проблем вызывать register() каждый раз, когда загружается страница; браузер выяснит, зарегистрирован ли сервис-воркер или нет, и обработает его соответствующим образом.

Установить сервис-воркер

Внутри нашего обратного вызова install нам нужно выполнить следующие шаги:
– Открыть кеш.
– Кэшировать наши файлы.
– Подтвердить, все ли необходимые ресурсы кешируются или нет.

var CACHE_NAME = ‘my-site-cache-v1’;
var urlsToCache = [
 ‘/’,
 ‘/styles/main.css’,
 ‘/script/main.js’
];
self.addEventListener(‘install’, function(event) {
 // Perform install steps
 event.waitUntil(
 caches.open(CACHE_NAME)
 .then(function(cache) {
 console.log(‘Opened cache’);
 return cache.addAll(urlsToCache);
 })
 );
});

Здесь вы можете видеть, что мы вызываем caches.open() с желаемым именем кеша, после чего мы вызываем cache.addAll() и передаем наш массив файлов. Это цепочка промисов (caches.open() и cache.addAll()). Метод события .waitUntil() принимает обещание и использует его, чтобы узнать, сколько времени займет установка и успешно ли она завершилась.
Определение длинного списка файлов повысит вероятность того, что файл может не кэшироваться, что приведет к тому, что ваш сервисный работник не будет установлен.

Использование сервисного работника

Много примеров первого использования и как получить из кеша можно найти здесь.

Более подробное объяснение с примерами и изображениями для пояснения можно найти здесь.

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

Добавление сервис-воркера в приложение React

В производственной сборке есть все инструменты, необходимые для создания первоклассного прогрессивного веб-приложения, но поведение «офлайн/сначала кэширование» доступно только по желанию. По умолчанию процесс сборки создаст рабочий файл службы, но он не будет зарегистрирован. Чтобы зарегистрировать его, перейдите в свой src/index.js и измените строку serviceWorker.unregister() в serviceWorker.register().

Что следует учитывать при выборе сервисных работников:

  • После выполнения начального кэширования жизненный цикл сервисного работника контролирует, когда обновленный контент будет показан пользователям. Чтобы защититься от условий гонки с ленивой загрузкой контента, поведение по умолчанию заключается в том, чтобы консервативно удерживать обновленный сервисный работник в состоянии «ожидания». Это означает, что пользователи в конечном итоге будут видеть старый контент, пока не закроют (перезагрузки недостаточно) свои существующие открытые вкладки. См. этот пост в блоге для получения более подробной информации об этом поведении.
  • Пользователи не всегда знакомы с автономными веб-приложениями. Может быть полезно сообщить пользователю, когда сервисный работник закончил заполнение ваших кешей (показывая сообщение «Это веб-приложение работает в автономном режиме!»), а также сообщить им, когда сервисный работник получит последние обновления, которые будут доступны в следующий раз, когда они загрузят страницу (показывая сообщение «Новый контент доступен после закрытия существующих вкладок».). Отображение этих сообщений в настоящее время оставлено разработчику в качестве упражнения, но в качестве отправной точки вы можете использовать логику, включенную в src/serviceWorker.js, которая демонстрирует, какие события жизненного цикла сервисного работника следует прослушивать для обнаружения каждого сценария, и который по умолчанию только записывает соответствующие сообщения в консоль JavaScript.
  • Сервисным работникам требуется HTTPS, хотя для облегчения локального тестирования эта политика не применяется к локальному хосту. Если ваш рабочий веб-сервер не поддерживает HTTPS, регистрация сервис-воркера завершится ошибкой, но остальная часть вашего веб-приложения останется работоспособной.
  • Сервисный работник включен только в производственной среде, например. вывод npm run build. Не рекомендуется включать автономный сервис-воркер в среде разработки, так как это может привести к разочарованию, когда используются ранее кэшированные ресурсы и не включают последние изменения, внесенные вами локально.
  • Если вам нужно локально протестировать автономный сервис-воркер, соберите приложение (используя npm run build) и запустите стандартный http-сервер из каталога сборки. После запуска сценария сборки приложение create-react-app предоставит инструкции для одного из способов локального тестирования рабочей сборки, а в инструкциях по развертыванию есть инструкции по использованию других методов. Обязательно всегда используйте окно инкогнито, чтобы избежать проблем с кешем браузера.
  • По умолчанию сгенерированный файл сервис-воркера не будет перехватывать или кэшировать трафик между источниками, например запросы HTTP API, изображения или встраивания, загруженные из другого домена.

Не забудьте адекватно настроить файл manifest.json.

Что нам нужно сделать, чтобы сделать наше PWA «установляемым»

В Chrome ваше прогрессивное веб-приложение должно соответствовать следующим критериям, прежде чем оно вызовет событие beforeinstallprompt и покажет продвижение установки в браузере:

  • Веб-приложение еще не установлено
  • Соответствует эвристике взаимодействия с пользователем
  • Обслуживаться по HTTPS
  • Включает манифест веб-приложения, который включает:
  • короткое_имя или имя
  • значки должны включать значки размером 192 и 512 пикселей.
  • start_url
  • отображение должно быть одним из следующих: полноэкранный, автономный или минимальный интерфейс.
  • Примечание. Параметр prefer_related_applications не должен присутствовать или иметь значение false.
  • Регистрирует работника службы с функциональным обработчиком выборки.

NB: Другие браузеры имеют схожие критерии установки, хотя могут быть небольшие отличия.