CacheStorage API позволяет безопасно сохранять данные в виде пар запрос-ответ. Это ключевой игрок, стоящий за офлайн-поддержкой прогрессивных веб-приложений. Со временем использование CacheStorage API развило несколько общих шаблонов, которые являются простыми, понятными и должны быть в состоянии обрабатывать 90% случаев использования. Большинство из них связаны с Service Worker API, но, конечно, не ограничиваются им, поскольку CacheStorage также доступен через глобальный объект window.
В этой статье мы рассмотрим шаблоны, использующие CacheStorage. Хотя речь идет об использовании CacheStorage, но мы будем использовать несколько функций Service Workers API и, наконец, Promise API, чтобы связать эти два. Ожидается очень базовое знание событий жизненного цикла обслуживающего работника и обещаний. Если вы не знакомы с CacheStorage API, вы можете быстро просмотреть предыдущую статью или ресурсы ниже. Давайте начнем с вариантов использования и рецептов cache
Пример использования:
Выполняйте предварительную загрузку всего статического содержимого приложения при обновлении для мгновенного использования в будущем, даже в автономном режиме.
Рецепт приготовления:
Мы будем использовать событие Service Worker install, чтобы перехватить первое посещение / обновление нашего приложения и добавить все ресурсы и пути, необходимые для нашего приложения. У вас должен быть уже размещенный список ресурсов и путей ... вы можете вручную заполнить массив, который также должен работать, но рекомендуется встроить это в сам процесс сборки.
Пример использования:
Очистите cache, удалив старый ненужный кеш.
Рецепт приготовления:
Событие Service Worker activate хорошо подходит для такого рода задач, так как мы уверены, что старый Service Worker был удален, а это управляет клиентами. Мы можем сделать это двумя способами. Одна из вещей может заключаться в том, чтобы добавить имя версии в конце каждого имени хранилища и удалить все те, которые не соответствуют версии валюты.
Пример использования:
Показывать содержимое из cache только для экономии трафика. Этот случай может быть очень полезен для статических ресурсов, таких как файлы CSS или javascript приложения, которые мы предварительно загрузили во время установки.
Рецепт приготовления:
В обработчике Service Worker fetch мы можем посмотреть, сделан ли запрос для одного из предварительно загруженных данных, и тогда мы ответим локальными данными напрямую, вместо того, чтобы идти в сеть ... обеспечивая быстрое и легкое обслуживание контента с точки зрения использования данных.
Пример использования:
У нас есть некоторые данные, которые мы хотим обновлять всегда, если у нас есть рабочее соединение. Но если у устройства нет подключения, мы хотим вернуться к сохраненному контенту. Например, комментарии к публикации в Facebook.
Рецепт приготовления:
Мы перехватим запрошенные данные и инициализируем сетевой вызов для запроса. Если сетевой запрос завершается успешно, мы затем обновляем кеш параллельно и отвечаем свежими данными. Но в случае, если сеть недоступна, мы можем напрямую доставить контент из самого кеша и показать пользователю какой-то пользовательский интерфейс, чтобы показать, что данные не свежие.
Пример использования:
Подумайте о приложении для музыкального плеера. Приложение кэширует последние 50 песен, а также песни, помеченные для автономного воспроизведения в кеше. Здесь имеет смысл фактически заглядывать в кеш всякий раз, когда перехватывается запрос песни, и, если он найден, немедленно обслуживать контент из кеша, не выходя в сеть. Но если контента нет… приложение должно получить его из сети, передать его пользовательскому интерфейсу, а также сохранить в кеше для использования в будущем.
Рецепт приготовления:
Это следует за несколько действительно простых шагов,
- заглядывать в кеш и обслуживать контент
OR
- получить, передать контент + сохранить в кеш.
Пример использования:
Предоставьте общий резервный контент. Например, чтобы показать запрещенную страницу пользовательского интерфейса, страницу 404 Not Found или даже настраиваемую автономную страницу, мы можем использовать хранилище кеша, предварительно выбрав требуемые данные на клиенте, а затем ответив в соответствии с запрошенный контент.
Рецепт приготовления:
Имея возможность перехватывать сетевые запросы, мы также можем проверить конкретный ответ сервера, чтобы предоставить специальный пользовательский интерфейс. Например, чтобы показать пользовательскую офлайн-страницу вместо страницы Динозавра или показать запрещенные страницы.
Пример использования:
Как я уже упоминал, CacheStorage действительно хорошо сочетается с Service Worker, но архитектура, основанная на обещаниях, и глобальная доступность действительно делают его бесплатным для всех видов использования и уловок.
Мы можем использовать caches для предварительной загрузки некоторых данных для использования в будущем, если пользователь того пожелает. Этого можно добиться, запустив предварительную выборку из CacheStorage, прослушивая пользовательские события.
Рецепт приготовления:
Процесс такой же. Предположим, существует какое-то приложение для воспроизведения музыки, которое хочет разрешить пользователю загружать списки воспроизведения для использования в автономном режиме или уменьшить сеть, часто добавляя списки воспроизведения в кеш. Как вы уже догадались, caches.addAll - это то, что нам здесь нужно.
Помимо взаимодействия с пользователем и рабочих событий, есть и другие способы использовать cache, такие как использование в сочетании с веб-push для периодического обновления данных приложения в фоновом режиме. Я надеюсь, что благодаря этой статье вы получите четкое представление о том, как подключать одни и те же функции по-разному для получения желаемых результатов, а также обрабатывать общие и крайние случаи автономной сети.
Дополнения / обзоры к статье приветствуются. Хотите поговорить о чём-то, давайте в комментариях или в твиттере просто 🔊🔊 @ritikrishu
