react service worker для чего
Разработка вашего первого Progressive Web App c React
Progressive Web Apps это разрекламированное будущее интернета. Давайте разработаем такое приложение!
Крупные игроки, такие как Twitter или Flipboard недавно запустили свои PWA, которые можно попробовать посетив с мобильного устройства страницы http://flipboard.com или https://lite.twitter.com/.
В этой статье, мы будем разрабатывать простое PWA с помощью React, которое даст нам шаблон для разработки более сложных приложений.
Настройка
Для начала, давайте создадим базовое React приложение с помощью create-react-app.
Перейдите в каталог в котором вы будете хранить ваше приложение и запустите следующие команды:
Теперь давайте установим React Router:
Наконец, скопируйте этот код в файл App.js. Он даст нам простой макет страницы с навигацией:
Запустите npm start чтобы протестировать ваше приложение. Смотреть ещё нечего, но для наших целей это хорошее начало. Давайте начнём конвертировать всё это в Progressive Web App.
1. Установка Lighthouse
Давайте установим его в Chrome, а после этого оценим нашем приложение. Вы можете запустить аудит Lighthouse кликнув по иконке в правом верхнем углу браузера, а затем нажав на кнопку «Generate Report».
Пока что наше приложение быстрое (так как у нас очень мало контента), но оно проваливается в большинстве ключевых областей.
Вы можете увидеть чек лист, который используется в Lighthouse здесь: https://developers.google.com/web/progressive-web-apps/checklist.
Давайте работать с проблемами по порядку.
2. Настройка Service Worker
Чтобы начать работу с Service Worker’ом, нам необходимо сделать 3 вещи:
Давайте сделаем это.
Чтобы сделать это, давайте добавим тег script в файл public/index.html.
Завершающий шаг: Настройка кэширования!
Мы собираемся скопировать настройки Service Worker’а отсюда написанные Addy Osmani, а также отключим кэширование в целях разработки (и предпримем меры удаления всего кэша, когда Service Worker инициализируется).
Перезапустите ваш приложение с помощью npm run start и вы должны увидеть следующее в консоле:
Давайте закроем консоль и запустим аудит Lighthouse снова:
Мы делаем успехи! Теперь у нас есть зарегистрированный Service Worker. Так как у нас отключено кэширование, вторая галочка ещё не отмечена, но как только мы включим кэширование она будет работать!
3. Добавление прогрессивных улучшений
Прогрессивные улучшения в основном означают, что сайт будет работать без загрузки любого JavaScript кода.
Вместо этого, мы хотим отображать какой-то базовый HTML и CSS, ещё до того как React приложение будет инициализировано.
Одобрит ли это Lighthouse?
Ага!
4. Возможность добавления на домашний экран
Ну а сейчас о том, что делает Progressive Web App действительно особенными: возможность пользователя сохранить его на свой домашний экран и открывать его как приложение.
Если у вас нету значка, то можете использовать этот (любезность моей компании MuseFind), или создайте свой собственный (должен быть 192 на 192 пикселя):
Хорошо, что теперь мы делаем?
Всё что нам не хватает, это кэширование и HTTPS.
5. Деплой через Firebase
Вернитесь в папку с проектом и запустите следующее:
После того как вы пройдёте авторизацию и начнётся инициализация: ответьте на следующие вопросы:
Нажмите Enter, а после этого выберите pwa-experiment в качестве проекта.
На вопрос про одностраничное приложение, выберите «No».
После этого процесс должен завершиться. Теперь можно запустить команду:
Firebase вернёт нам URL. Давайте откроем его в Chrome и запустим аудит Lighthouse в заключительный раз.
Ну и в качестве завершающего теста, откройте этот URL на вашем телефоне и попробуйте сохранить его на домашний экран. После открытия его с домашнего экрана, он должен выглядеть как нативное приложение.
Куда двигаться дальше
Однако, по мере роста вашего приложения, файл main.js будет увеличиваться и увеличиваться, и Lighthouse будет всё меньше и меньше доволен вами.
Следите за нами, чтобы не пропустить углублённую статью об оптимизации производительности с помощью React и React Router, которая будет применима как и для Progressive Web App так и для старомодных веб-приложений.
Теперь у нас есть рабочий скелет для разработки PWA и мы готовы к будущему веб-приложений.
Все, что вы хотели знать о Service Worker
Дата публикации: 2020-03-18
От автора: этот пост полностью посвящен Service Worker, как он работает, где мы можем его использовать, как мы можем удалить это, где он не будет работать и многое другое.
Service Worker
Service Worker — это файл скрипта Java, который запускается в браузере пользователя как фоновый процесс.
Как работает Service Worker
Он перехватывает сетевые запросы, кэширует или извлекает ресурсы из кэша, а также доставляет push-уведомления. К Service Worker может одновременно обращаться множество вкладок в браузере, поскольку только один Service Worker может существовать в каждой области, а его существование не зависит от основного потока.
Чтобы установить Service Worker в проекте, сначала необходимо зарегистрировать Service Worker.
Регистрация Service Worker
Чтобы зарегистрировать Service Worker, нам нужно проверить, поддерживает ли его браузер, используя Объект navigator. Объект navigator содержит информацию о браузере. Ваш первый Service Worker загружается, когда вы вызываете функцию register().
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Service Worker может получить доступ только к папкам, расположенным ниже, поэтому, вероятно, лучше хранить его в корне проекта (самая верхняя папка).
Функция регистрации Service Worker загружает скрипт Service Worker с предоставленного URL-адреса и выполняет его.
В приведенном выше коде ответ содержит информацию о состоянии Service Worker, а также о его объеме. В файле ServiceWorker.js мы можем написать код для установки, обновления, отправки и т. д.
Если Service Worker не удается зарегистрировать, промис регистрации отклоняется, и Service Worker отбрасывается.
Как добавить Service Worker
После успешной регистрации Service Worker может выполняться установка. Установка Service Worker:
Если Service Worker новый или обновленный, начнется процесс установки. На этом этапе вы можете кэшировать статический контент или файл.
Это событие срабатывает только в том случае, если «ServiceWorker.js» не существует или файл более новой версии (обновлен).
Service Worker не устанавливается, если какой-либо файл не удалось перехватить, что предусмотрено функцией cache.addAll().
С помощью event.waitUntil() Service Worker не завершает работу, пока промис, переданный методу waitUntil(), не будет разрешен или отклонено. После успешной установки запускается событие активации Service Worker.
Как очистить кэш Service Worker
В случае активации мы можем удалить существующий кэшированный элемент с помощью метода cache.delete().
Метод caches.keys() предоставляет имена всех доступных кэшей. Каждый раз, когда пользователь делает запрос на странице, запускаются события кэширования Service Worker. В этом случае мы решаем, хотим ли мы, чтобы этот запрос был передан в сеть или был представлен элемент из кэша.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Предоставляем ответ с помощью сетевого вызова.
Метод responseWith() позволяет вам предоставить промис на Response самостоятельно.
Обновление Service Worker
Если мы внесем изменения в файл скрипта Service Worker, то браузер будет считать его новым Service Worker, и будет запущено новое событие установки.
Когда мы обновляем Service Worker, новый Service Worker не контролирует клиенты, потому что клиентов обрабатывает старый Service Worker. Когда мы закрываем браузер, старый Service Worker уничтожается, а новый заменяет старый Service Worker.
Если мы хотим использовать нового Service Worker, как только установка будет завершена, мы можем использовать метод self.skipWaiting().
Этот метод активирует Service Worker после завершения установки. Если новый Service Worker не удается установить, клиентов (страницы) продолжает обрабатывать старый. В режиме разработки установите флажок обновления при перезагрузке, тогда Service Worker будет обновляться при обновлении страницы.
Отладка Service Worker
Service Worker доступны только для «безопасных источников» (HTTPS-сайты, в основном). Чтобы проверить Service Worker в Chrome:
Перейдите к инструментам разработчика (F12) или кликните правой кнопкой мыши на странице и выберите «Просмотреть». Перейти на вкладку приложения, а кликните на Service Worker в боковой панели. В боковой панели будет отображен список зарегистрированных Service Worker.
Как проверить Service Worker на localhost:
Для разработки Вы можете использовать localhost, так как localhost также считается «безопасным источником». Или настройте локальный сервер, используя http-сервер npm и обслуживая пакет.
Service Workers. Инструкция по применению
Количество выходов в интернет с мобильных устройств ежегодно растёт на 2-4% в год. Качество связи не успевает за такими темпами. Как итог, даже самое лучшее веб-приложение обеспечит ужасный опыт, если пользователь не сможет его загрузить.
Проблема в том, что до сих пор нет хорошего механизма управления кэшем ресурсов и результатов сетевых запросов. В своей статье я хочу рассказать как Service Worker (SW) может помочь в решении этой задачи. Объясню в формате рецептов — какие элементы и в какой пропорции смешать, чтобы получить нужный результат, исходя из задачи и требований.
До появления SW проблему работы в offline-режиме решал другой API — AppCache. Однако наряду с подводными камнями AppCache фигурировал факт, что он отлично работает в single-page приложениях, но не очень хорошо подходит для многостраничных сайтов. SW разрабатывались, чтобы избежать этих проблем.
Что такое Service Worker?
Во-первых, это скрипт, который браузер запускает в фоновом режиме, отдельно от страницы, открывая дверь для возможностей, не требующих веб-страницы или взаимодействия с пользователем. Сегодня они выполняют такие функции как push-уведомления и фоновая синхронизация, в будущем SW будут поддерживать и другие вещи. Ключевая их особенность — это возможность перехватывать и обрабатывать сетевые запросы, включая программное управление кэшированием ответов.
Во-вторых, SW запускается в worker контексте, поэтому он не имеет доступа к DOM и работает в потоке, отдельном от основного потока JavaScript, управляющего вашим приложением, а следовательно — не блокирует его. Он призван быть полностью асинхронным, поэтому использовать синхронные API (XHR и LocalStorage) в SW нельзя.
В-третьих, из соображений безопасности SW работают только по HTTPS, так как давать посторонним людям возможность изменять сетевые запросы крайне опасно.
Что нужно кэшировать?
Для того чтобы приложение стало более отзывчивым, нам нужно кэшировать все статичные файлы:
Почему мы не можем использовать LocalStorage для подобной ситуации?
Всё очень просто. LocalStorage — синхронный API, имеет ограничение в 5MB и позволяет хранить только строки.
У SW с этим всё лучше: он асинхронный, является прокси для запросов, что позволяет обрабатывать и кэшировать любой запрос и согласно статье Offline Storage for Progressive Web Apps от Эдди Османи:
Мне уже нравится Service Worker. Как его использовать?
Ниже я расскажу про рецепты приготовления SW для создания отзывчивых и понятных приложений.
Заготовки для приготовления Service Workers
Для написания своего собственного SW нам понадобятся:
В файле sw.js нам нужно лишь определить базовые события, на которые будет реагировать SW.
Подробности про lifecycle для SW вы можете узнать из данной статьи.
Рецепт №1 — Network or cache
Подходит для медийных сайтов, где очень много медиа-контента. Картинки и видео могут отдаваться долго, наша задача закэшировать их. При последующих запросах на сервер мы будем отдавать данные из кэша. Имеем в виду, что данные могут быть уже неактуальными, для нас главное здесь — избавить пользователя от ожидания загрузки файлов.
Решение
Данный вариант подойдёт, если скорость загрузки контента для вас приоритетна, но хотелось бы показать наиболее актуальные данные.
Механизм работы следующий: идёт запрос на ресурс с ограничением по времени, например 400ms, если данные не были получены в течении этого времени, мы отдаём их из кэша.
SW в этом рецепте пытается получить самый актуальный контент из сети, но если запрос занимает слишком много времени, то данные будут взяты из кэша. Эту проблему можно решить путём выставления timeout’а на запрос.
Рецепт №2 — Cache only
Идеальный рецепт для лендингов, задача которых — продемонстрировать пользователю продукт и тем самым задержать его внимание на сайте. Медленная загрузка контента при плохом соединении в данном случае просто неприемлема, поэтому приоритет данного рецепта — отдача данных из кэша при любом соединении. Исключение — первый запрос и чистка кэша. Минус способа в том, что если вы измените контент, то у пользователей перемена произойдет после того, как кэш станет невалидным. По умолчанию SW делают перерегистрацию через 24 часа после установки.
Решение
Всё, что мы делаем, это при регистрации SW складываем в кэш все наши статичные ресурсы; при последующих обращениях к ресурсам SW всегда будет отвечать данными из кэша.
Рецепт №3 — Cache and update
Данный рецепт решает проблему актуальности данных, чего не было в рецепте №2.
Иными словами мы получим обновлённый контент, но с задержкой до следующей загрузки страницы.
Решение
Как и в предыдущем варианте, в данном рецепте SW сначала отвечает из кэша, чтобы доставить быстрые ответы, но при этом обновляет данные кэша из сети.
Рецепт №4 — Cache, update and refresh
Расширение рецепта №3. В данном решении мы обновляем контент в фоне, но всегда можем указать пользователю, что данные на странице поменялись. Примером может служить создание приложений, в которых происходит редактирование контента в фоне. Так, вы читаете статью на новостом сайте и получаете уведомление о том, что данные на странице обновились и появилась более свежая информация.
Решение
Рецепт позволяет SW отвечать из кэша, чтобы отдавать быстрые ответы, а также обновлять данные в кэше из сети. Когда запрос выполнится успешно, пользовательский интерфейс будет обновлён автоматически или посредством UI-контрола.
Используйте содержимые данные из кэша, но в то же время выполняйте запрос на обновление записи кэша и информируйте UI о новый данных.
Рецепт №5 — Embedded fallback
Существует проблема, когда браузер по умолчанию выдаёт вам сообщение о том, что вы офлайн. Я называю это проблемой, так как:
Решение
Нужно отдать fallback-данные, если нет доступа к ресурсам (сеть и кэш).
Данные подготавливаются заранее и кладутся как статичные ресурсы, доступные SW.
Заключение
Выше мы рассмотрели базовые рецепты применения SW для приложений.
Они описаны по мере усложнения. Если у вас простой лендинг — не нужно лезть в дебри, просто используйте Cache only или Network or cache. Для более сложных приложений используйте остальные рецепты.
Статья задумывалась начальной в серии статей о SW API. Хочется понять, насколько тема интересна и полезна. Жду ваших комментариев и пожеланий.
Кто ты такой, Service Worker?
Service Worker: Я программируемый сетевой проксификатор.
Service Worker звучит круто, но я не очень то понимаю что это
В июле 2015 я участвовала в конференции по JavaScript, проходившей в городе Остин, штат Техас. На сцене — Джейк Арчибальд, которого тогда я знала как забавного британского парня, любителя пошутить на “туалетную тему” 🚽. Уже потом я поняла, что он вполне себе “важный чувак” и является одним из разработчиков спецификации Service Worker’ов.
И вот по ходу истории об UX-откровении, настигнувшем его в общественном туалете, Джейк рассказал залу о новой штуке, названной Service Worker. Штуке, позволяющей вашему веб-сайту вести себя как нативное приложение (по крайней мере тогда я поняла его именно так).
То, о чем он говорил, звучало невероятно, и мне захотелось попробовать технологию на своем проекте. Сначала было немного трудно понять что это… Это не библиотека, не новый HTML элемент и даже не новый JavaScript синтаксис, а такие термины как “кэш” или “прокси” всегда приводили меня в замешательство. Пытаясь разобраться в принципах работы Service Worker’а, я делала пометки на бумаге, и мне в голову пришла идея сравнить его с “пришельцем, которого вы приглашаете пожить в вашем браузере”. Звучит странно? Тогда давайте попробуем разобраться.
S ervice Worker — пришелец во вселенной веб-браузера.
Представьте: ваш браузер — это планета (наподобие Земли), частица большой галактики вашего компьютера. Люди на этой планете разговаривают на своих языках, таких как HTML, CSS и JavaScript, благодаря которым они формируют сообщества — веб страницы.
И если вы веб-разработчик, вы должны хорошо разбираться как функционируют эти сообщества: начиная от их разнообразных элементов и DOM дерева и заканчивая режимами обновления данных на вашем сайте.
На этой планете (в браузере) был придуман способ общения с внешним миром, который позволил запрашивать информацию из других галактик (серверов). Его назвали Hyper Text Transfer Protocol. Именно так ваша планета-браузер превратилась в копилку милых картинок с котятами и ненужных твитов. И именно так она смогла привлечь к себе миллионы постоянных пользователей.
HTTP похож на невероятную волшебную вещицу, однако, чтобы она работала, вам нужен Интернет. Представим его как длинный многоколенчатый трубопровод. Интернет обеспечивает нам необходимое сообщение с удаленными серверами-галактиками. Длина такого трубопровода зависит от того, сколько вы платите обслуживающей организации (интернет-провайдеру), и от качества инфраструктуры в вашем регионе. Если ваша труба узкая или слишком длинная, то и данные из других галактик поступают на вашу планету дольше.
Но дело в том, что Интернет порой оказывается и вовсе недоступным для вашего браузера. В такие периоды ваша планета возвращается в доисторическую эпоху, и никакие из современных вещей вам не доступны, а ваш браузер показывает картинки динозавров, как напоминание о “старых добрых”.
Но подождите! Service Worker уже здесь, чтобы помочь!
Три вещи, которые следует знать о вашем новом приятеле.
Итак, какого типа работу может выполнить для вас Service Worker?
1. Взаимодействие с кэшем
Вы можете попросить Service Worker отслеживать fetch events и сохранять определенные ресурсы в кэше. Позже, когда эти ресурсы понадобятся, он передаст их вашему сайту, а делать внешний HTTP-запрос будет уже не нужно. Таким образом, если необходимые данные предварительно закэшированы, браузер сможет показывать контент веб-страниц даже при отсутствии интернет-подключения.
2. Push-уведомления
Благодаря магии, по которой Service Worker работает даже при выключенном браузере, вы можете всегда быть в курсе, получая push-уведомления.
3. Фоновая синхронизация
Активность при закрытом браузере означает еще и то, что Service Worker будет работать, не отвлекая внимания пользователя на текущие процессы. Скажем, вы используете веб-страницу, будучи offline, но вам необходимо отправить файл. Так вот, Service Worker сам отправит файл на сервер, когда интернет станет доступен снова.
Использование Service Worker
В данной статье содержится информация о начале работы с сервис-воркерами, включая базовую архитектуру, процесс регистрации, а также установку и активацию новых сервис-воркеров, обновление существующих сервис-воркеров, управление кешем и настраиваемые ответы и все это в контексте простого приложения с офлайн-функциональностью.
Предпосылки появления Service Workers
Одной из важнейших проблем, от которой страдали пользователи веб-приложений, была работа в условиях потери связи. Лучшее в мире веб-приложение оставит ужасное впечатление от использования, если вы не сможете его загрузить. Предпринималось много попыток создания технологий, которые бы решили эту проблему, и если верить страницам нашего Форума, некоторые из вопросов были решены. Но всё же наиважнейшей проблемой по-прежнему является отсутствие хорошего механизма для управления кешем ресурсов и настраиваемыми сетевыми запросами.
Предыдущей попыткой была технология AppCache, казавшаяся хорошей идеей, потому как позволяла действительно просто указывать ресурсы для кеширования. Однако, эта технология допускает много предположений о том, что вы пытаетесь сделать, и затем с грохотом ломается, когда ваше приложение работает не в точности с этими допущениями. Чтобы получить больше информации по этой теме, прочитайте (неудачно названную, но хорошо написанную) статью Джейка Арчибальда Application Cache is a Douchebag.
На заметку: Начиная с Firefox 44, когда используется AppCache для предоставления странице поддержки офлайн-режима, в консоли разработчика отображается предупреждение о том, что нужно использовать технологию Service Workers (баг 1204581.)
Технология Service Workers должна в итоге решить озвученные выше вопросы. Синтаксис Service Worker более сложен, чем тот же AppCache, но взамен вы можете посредством JavaScript контролировать AppCache-подразумеваемое поведение с высокой степенью детализации, что позволяет вам решить описанную проблему и многие другие. Используя Service Worker, вы можете без труда получить приложение, использующее в первую очередь кешированные ресурсы, предоставляя тем самым поведение по умолчанию в автономном режиме, до того как будет получено по сети больше данных (такой подход называется Offline First). Так обычно работают нативные приложения, что часто является причиной выбора пользователя в их пользу.
Что нужно настроить, чтобы поиграть с Service Worker
Многие функции Service Worker теперь включены по умолчанию в новых браузерах, поддерживающих эту технологию. Однако, если вы обнаружите, что демонстрационный код не работает в вашей версии браузера, вам может понадобиться их включить:
Также вам необходимо предоставлять ваш код по протоколу HTTPS — Service Worker требует этого по соображениям безопасности. По этой причине GitHub — хороший выбор для экспериментов, поскольку он поддерживает протокол HTTPS по умолчанию. Для облегчения локальной разработки браузеры считают localhost также безопасным origin.
Базовая архитектура
Чтобы сделать базовую настройку Service Worker, как правило, нужно пройти следующие шаги:
Следующий рисунок кратко показывает доступные события Service Worker:
Промисы
Промисы — отличный механизм для запуска асинхронных операций, которые могут успешно зависеть друг от друга. Промисы имеют большое значение в работе сервис-воркеров.
Давайте сравним структуру традиционного синхронного колбэка с его промис-эквивалентом.
async
Вместо этого мы можем написать собственный промис для работы с подобными случаями. (Вы можете найти исходный код в нашем примере Promises test или взглянуть на живое демо.)
Все это происходит асинхронно.
На заметку: вы можете также объединять вызов нескольких промис-методов в одну цепочку, как в этом примере:
myPromise().then(success, failure).then(success).catch(failure);
На заметку: вы можете получить гораздо больше информации о промисах, прочитав превосходную статью Джейка Арчибальда (Jake Archibald’s) JavaScript Promises: there and back again.
Демонстрация Service Workers
Чтобы продемонстрировать только базовые моменты регистрации и установки сервис-воркеров, мы создали простое демо-приложение, названое sw-test. Это простая галерея изображений «Star wars Lego». Оно использует промис-функции, чтобы прочитать из JSON-объекта и загрузить, используя технологию Ajax, изображения, находящиеся далее нижнего края страницы, до того как они будут показаны. В приложении также ещё регистрируется, устанавливается и активируется сервис-воркер, и, в случае если браузер поддерживает спецификацию Service Worker, запрашиваемые ресурсы будут закешированы, и приложение будет работать в офлайн-режиме!
Вы можете посмотреть исходный код на GitHub, а также этот живой пример. Единственное, что мы тут рассмотрим, это промис (смотрите app.js строки 22-47), модифицированная версия того, о котором вы читали выше в разделе Тестовая демонстрация промисов. Разница в следующем:
Погружение в Service Worker
Итак, переходим к Service Worker!
Регистрация воркеров
Ниже представлен первый блок кода файла app.js. Это точка входа в Service Worker.
Предыдущий код регистрирует сервис-воркера, который работает в worker-контексте, и следовательно, не имеет доступа к DOM. Затем вы запускаете код в сервис-воркере, вне ваших страниц, чтобы контролировать их загрузку.
Один сервис-воркер может контролировать несколько страниц. Каждый раз, когда загружается страница, находящаяся в пределах области видимости, сервис-воркер будет установлен на ней и начнёт работу. Поэтому будьте осторожны с применением глобальных переменных в скриптах сервис-воркеров, потому как у каждой страницы нет своего уникального экземпляра сервис-воркера.
На заметку: Сервис-воркеры функционально похожи на прокси-серверы, они позволяют модифицировать запросы и ответы, замещая записями из собственного кеша, и многое другое.
На заметку: Есть одна очень хорошая особенность при работе с сервис-воркерами. В случае, если вы используете функциональность проверки поддержки Service Worker, то приложение в браузерах, не имеющих поддержки, продолжат нормально работать с ожидаемым поведением. Кроме того, если браузер поддерживает только AppCache, то будет использована эта технология. В случае, если браузер поддерживает и AppCache и Service Worker, то будет использована Service Worker.
Почему мой сервис-воркер не прошёл регистрацию?
Это может произойти по следующим причинам:
Также обратите внимание:
Установка и активация: заполнение кеша
После того как ваш сервис-воркер будет зарегистрирован, браузер может попробовать установить его и активировать на странице/сайте.
Событие install возникает после того как установка успешно завершится. Это событие используется главным образом для того, чтобы заполнить кеш браузера ресурсами, необходимыми для успешного запуска в офлайн-режиме. Для этого используется новый API хранилища Service Worker — cache — глобальный для всех сервис-воркеров, который позволяет нам хранить результаты запросов, используя в качестве ключа для их получения сами запросы. Этот API работает аналогично стандартному кешу браузера, но только для вашего домена. Данные в кеше сохраняются до тех пор, пока вы сами не решите их удалить — вы имеете полный контроль.
На заметку: Cache API поддерживается не всеми браузерами (смотрите раздел Browser support чтобы получить больше информации). Если вы хотите сейчас использовать эту технологию, то можете рассмотреть возможность использования полифила, который доступен в Google’s Topeka demo, или можете хранить ресурсы в IndexedDB.
Давайте начнём этот раздел посмотрев на фрагмент кода ниже — это первый блок кода, который вы увидите в нашем сервис-воркере:
На заметку : localStorage работает схожим образом, но в синхронном режиме, поэтому запрещён в сервис-воркерах.
На заметку : При необходимости хранить данные в сервис-воркерах вы можете использовать IndexedDB.
Настраиваемые ответы на запросы
Событие fetch возникает каждый раз, когда запрашиваются любые подконтрольные сервис-воркеру ресурсы, к которым относятся документы из области видимости и другие ресурсы, связанные с этими документами (например, если в index.html происходит кросс-доменный запрос для загрузки изображения, то он тоже попадёт в сервис-воркер).
Для начала, на каждый сетевой запрос мы можем отдать в ответ ресурс, чей url соответствует запросу:
caches.match(event.request) позволяет нам проверять сетевой запрос ресурса на соответствие какому-либо доступному в кеше ресурсу, если такой ресурс имеется. Соответствие проверяется по url и изменяемым заголовкам.
Давайте рассмотрим несколько других вариантов реализации нашей магии (чтобы получить больше информации об интерфейсах Request и Response смотрите документацию к Fetch API.)
Конструктор Response() позволяет вам создавать собственные ответы. В данном случае, мы всего лишь возвращаем простую текстовую строку:
В этом более сложном объекте Response показано, как вы можете передать набор заголовков в свой ответ, эмулируя стандартный HTTP-ответ. Здесь мы просто сообщаем браузеру, чем является содержимое ответа:
Если совпадение не было найдено в кеше, вы можете попросить браузер загрузить (en-US) тот же ресурс, чтобы получить новый файл через обычную сеть, если она доступна:
Если информация, соответствующая запросу, в кеше не найдена, а также сеть не доступна, то вы можете просто ответить на запрос какой-либо страницей по умолчанию, которая хранится в кеше, используя match() :
Восстановление неудачных запросов
Итак, caches.match(event.request) отработает как нужно только в том случае, если в кеше сервис-воркера будет найдено соответствие запросу. Но что произойдёт, если такого соответствия не будет найдено? Если мы не предоставим никакого механизма обработки такой ситуации, то промис выполнится со значением undefined и мы не получим никакого значения.
К счастью, сервис-воркеры имеют структуру основанную на промисах, что делает тривиальной такую обработку и предоставляет большое количество способов успешно обработать запрос:
Если промис будет отклонён, функция catch() вернёт обычный сетевой запрос к внешнему ресурсу. Это значит, что, если сеть доступна, то ресурс просто загрузится с сервера.
Если же мы были достаточно умны, то мы не стали бы просто возвращать сетевой запрос, а сохранили бы его результат в кеше, чтобы иметь возможность получить его в офлайн-режиме. В случае с нашим демо-приложением «Star Wars gallery», это означает, что, если в галерею будет добавлено ещё одно изображение, то оно будет получено и сохранено в кеше:
Почему? Потому что потоки запроса и ответа могут быть прочитаны только единожды. Чтобы ответ был получен браузером и сохранён в кеше, нам нужно клонировать его. Так оригинальный объект отправится браузеру, а клон будет закеширован. Оба они будут прочитаны единожды.
Обновление вашего сервис-воркера
Если после того, как ваш сервис-воркер был установлен, стала доступна его новая версия, при обновлении или загрузке страницы она будет установлена в фоновом режиме, но не будет активирована. Она будет активирована, лишь когда не останется ни одной страницы, использующей старую версию сервис-воркера.
Вы можете обновить обработчик события install в новой версии сервис-воркера, чтобы получить примерно такое (обратите внимание на номер новой версии):
В то время, как этот код работает, предыдущая версия также доступна. Новая версия устанавливается в фоновом режиме. Мы можем работать с версией кеша v2, в то время как версия v1 не будет разрушена.
Когда ни одна страница не будет использовать текущую версию, новый воркер активируется и станет ответственным за обработку всех запросов.
Удаление старого кеша
Вы можете обрабатывать событие activate. Оно обычно используется в случае, если нужно выполнить такие действия, которые бы нарушили работу воркеров предыдущей версии, если они все ещё работают со старым кешем. Также это событие полезно использовать для того, чтобы удалить ненужные данные, чтобы освободить место, занимаемое на диске, потому что каждый браузер имеет жёсткие ограничения на размер хранилища кеша, которое доступно для использования сервис-воркерами.
Инструменты разработчика
Firefox также начал реализовывать полезные инструменты для разработки сервис-воркеров: