маленькие герои прогрессивных веб-программ

malenkie geroi progressivnyh veb programm

Хотите изучить JavaScript? Получите мою электронную книгу на jshandbook.com

Сервисные работники являются основой прогрессивных веб-приложений. Они позволяют кэшировать ресурсы и push-сообщения, являющиеся двумя основными отличительными чертами, которые к этому моменту отличали нативные программы.

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

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

Поскольку он находится в отдельном потоке, он не имеет доступа к DOM. Он также не имеет доступа к API локального хранилища и API XHR. Он может только возвращаться к основному потоку с помощью API обмена сообщениями канала.

Service Workers сотрудничают с другими последними веб-API:

  • Обещания
  • API Fetch
  • API кэша

И они есть доступно только на HTTPS страницы протокола (за исключением локальных запросов, для которых не требуется безопасное соединение. Это облегчает тестирование).

Фоновая обработка

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

К примеру, они могут работать:

  • когда ваше мобильное приложение в фоновом режименеактивный
  • когда ваше мобильное приложение ЗАКРЫТ и даже не работает в фоновом режиме
  • когда браузер закрытесли приложение запущено в браузере

Основные сценарии, когда сервисные работники очень полезны:

  • Их можно использовать как a слой кэширования для обработки сетевых запросов и кэширования содержимого для использования в автономном режиме
  • Могут разрешить push-сообщение

Сервис-воркер запускается только при необходимости и останавливается при неиспользовании.

Офлайн-поддержка

Традиционно работа веб-приложений в автономном режиме была очень плохой. Без сети часто мобильные веб-приложения просто не будут работать. Нативные мобильные приложения, с другой стороны, могут предложить либо рабочую версию, либо какое-нибудь приятное сообщение.

Это неприятное сообщение, но вот как выглядят веб-страницы в Chrome без подключения к сети:

dS6TKfY7CA6UEOB2OUVeausTK3eyPx2DSZ76

Возможно, единственная приятная вещь в этом состоит в том, что вы можете играть в бесплатную игру, щелкнув динозавра – но это довольно быстро надоедает.

56VoLGuQErxh7lGJGDLw-Iuj0TpBsUXE2ZBH

Недавно HTML5 AppCache уже обещал разрешить веб-приложениям кэшировать ресурсы и работать в автономном режиме. Но его недостаточная гибкость и непонятное поведение дали понять, что он недостаточно хорош для работы (и он был прекращен).

Service Workers – это новый стандарт оффлайн-кэширования.

Какой вид кэширования возможен?

Предварительное кэширование ресурсов при установке

Ресурсы, повторно используемые в программе, такие как изображения, CSS, файлы JavaScript, можно установить при первом открытии программы.

Это дает основу того, что называется Архитектура App Shell.

Кэширование сетевых запросов

Используя Fetch API, мы можем редактировать ответ, поступающий от сервера, определяя, доступен ли сервер, а затем предоставляя ответ из кэша.

Жизненный цикл Service Worker

Сервис-воркер проходит три шага, чтобы стать полностью функциональным:

  • Регистрация
  • монтаж
  • активация

Регистрация

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

Пример кода для регистрации сервисного работника worker.js:

if ('serviceWorker' in navigator) {   window.addEventListener('load', () => {       navigator.serviceWorker.register('/worker.js')     .then((registration) => {       console.log('Service Worker registration completed with scope: ', registration.scope)     }, (err) => {       console.log('Service Worker registration failed', err)    })  })} else {   console.log('Service Workers not supported') }

Даже если этот код будет вызван несколько раз, браузер выполнит регистрацию, только если сервис-воркер новый и не зарегистрирован ранее или если он был обновлен.

Область применения

The register() call также принимает параметр области действия, который является путём, определяющим, какой частью вашей программы может управлять сервисный работник.

По умолчанию все файлы и вложенные папки содержатся в папке, содержащей файл службы worker, поэтому если вы поместите его в корневую папку, он будет иметь контроль над всей программой. Во вложенной папке он будет управлять только страницами, доступными по этому маршруту.

В нижеприведенном примере регистрируется работник с указанием /notifications/ объем папки.

navigator.serviceWorker.register('/worker.js', {   scope: '/notifications/' })

The / важно: в этом случае страница /notifications не запускает Service Worker, если область была

{ scope: '/notifications' }

это бы сработало.

ПРИМЕЧАНИЕ: Service Worker не может «поднять» себя из папки: если его файл находится под /notificationsон не может контролировать / путь или любой другой путь, который не под /notifications.

монтаж

Если браузер определит, что Service Worker устарел или никогда не был зарегистрирован, он продолжит его установку.

self.addEventListener('install', (event) => {   //... });

Это отличное время, чтобы подготовить сервисного работника, который будет использоваться инициализация кэша. Затем кэшировать оболочку программы и статические активы с помощью API кэша.

активация

После успешной регистрации и инсталляции сервисного работника третьим шагом является активация.

На этом этапе сервис-воркер сможет работать с новыми загрузками страниц.

Он не может взаимодействовать с уже загруженными страницами, поэтому сервис-воркер полезен только тогда, когда пользователь вторично взаимодействует с приложением или перезагружает одну из открытых страниц.

self.addEventListener('activate', (event) => {   //... });

Хорошим вариантом использования этого события является очищение старых кэшей и вещей, связанных со старой версией, которые не используются в новой версии сервисного работника.

Обновление Service Worker

Чтобы обновить сервис-воркер, нужно просто сменить в нем один байт. При запуске кода регистрации он будет обновлен.

После обновления Service Worker он не станет доступен, пока не будут закрыты все страницы, загруженные со старым Service Worker.

Это гарантирует, что ничего не сломается на уже работающих программах/страницах.

Обновления страницы недостаточно, поскольку старый рабочий файл все еще работает и не удален.

Получить события

А получить событие запускается, когда в сети запрашивается ресурс.

Это дает нам возможность посмотрите в кэш перед отправкой сетевых запросов.

Например, приведенный ниже фрагмент использует API кэша чтобы проверить, сохранен ли URL-адрес в кэшированных ответах. Если это так, он возвращает кэшированный ответ. В противном случае он выполняет запрос на выборку и возвращает его.

self.addEventListener('fetch', (event) => {  event.respondWith(     caches.match(event.request)       .then((response) => {         if (response) {           //entry found in cache           return response         }         return fetch(event.request)       }     )   ) })

Фоновая синхронизация

Фоновая синхронизация позволяет откладывать исходные соединения, пока у пользователя нет рабочего соединения с сетью.

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

navigator.serviceWorker.ready.then((swRegistration) => {   return swRegistration.sync.register('event1') });

Этот код прослушивает событие в Service Worker:

self.addEventListener('sync', (event) => {   if (event.tag == 'event1') {     event.waitUntil(doSomething())   } })

doSomething() возвращает обещание. Если это не удастся, другое событие синхронизации будет запланировано для автоматической повторной попытки, пока оно не удастся.

Это также позволяет приложению обновлять данные с сервера, как только появится рабочее соединение.

Push Events

Служебные работники позволяют веб-приложениям предоставлять пользователям собственные Push-сообщения.

Push и Notifications – это фактически две разные концепции и технологии, которые сочетаются, чтобы обеспечить то, что мы знаем как Push-уведомление. Push обеспечивает механизм, позволяющий серверу посылать информацию сервисному воркеру, а уведомление – это способ, которым сервисный воркер может показать информацию пользователю.

Поскольку сервис-воркеры работают даже тогда, когда приложение не работает, они могут прослушивать поступления событий push. Затем они либо сообщают пользователям, либо обновляют состояние программы.

Push-события инициируются серверной частью через службу push-рассылки браузера, например, которую предоставляет Firebase.

Вот пример того, как веб-воркер может прослушивать входящие push-события:

self.addEventListener('push', (event) => {   console.log('Received a push event', event) 
  const options = {     title: 'I got a message for you!',     body: 'Here is the body of the message',     icon: '/img/icon-192x192.png',     tag: 'tag-for-this-notification',   } 
  event.waitUntil(     self.registration.showNotification(title, options)   ) })

Примечание к журналам консоли:

Если у вас есть любой оператор журнала консоли (console.log и друзья) в сервисном работнике, убедитесь, что вы включили Preserve log функция, предоставляемая Chrome Devtools (или эквивалентом).

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

Хотите изучить JavaScript? Получите мою электронную книгу на jshandbook.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *