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

Давайте займемся одной проблемой за раз.

Запретить запросы к серверу

Так как же предотвратить запрос сервера без изменения производственного кода? На самом деле это довольно просто - используйте рабочую панель;). Я уже написал пару сообщений в блоге (Vue PWA Plugin, Vue PWA And IndexedDB) о том, как настроить сервис-воркер с Vue PWA Plugin. Поэтому сначала ознакомьтесь с ними.

Единственная команда, которая вам сейчас нужна:

vue add @vue/pwa

Это добавит все необходимые файлы в ваш проект, и все готово.

Как вы ставите в очередь свои почтовые запросы

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

Опять же, в этом случае workbox действительно прост в использовании. Чтобы добавить эту возможность, добавьте только эти строки в свой service-worker.js

const bgSyncPlugin = new workbox.backgroundSync.Plugin('queueExample', {
  maxRetentionTime: 24 * 60 // Retry for max of 24 Hours
});
workbox.routing.registerRoute(
  'https://jsonplaceholder.typicode.com/posts',
  workbox.strategies.networkOnly({
    plugins: [bgSyncPlugin]
  }),
  'POST'
);

Первая строка определяет плагин и как долго он должен работать. В моем случае я хочу включить синхронизацию как минимум на 24 часа. В зависимости от вашего варианта использования вы можете увеличить это время. Следующий блок определяет, что происходит при вызове URL-адреса https://jsonplaceholder.typicode.com/posts. Я использую стратегию networkOnly, которая будет использовать bgSyncPlugin, определенный выше. Поэтому каждый раз, когда у меня нет подключения к Интернету, будет использоваться этот плагин.

Чтобы протестировать реализацию, посетите: workbox-sync (Подсказка: НЕ ИСПОЛЬЗУЙТЕ CHROME DEVTOOLS ОФФЛАЙН). Хотя кешированный запрос появится в вашей indexedDB, все остальное не будет работать правильно.

Так как же выглядит кешированный запрос?

Вот и все. Запросы будут кэшироваться вашей indexedDB и синхронизироваться, как только у вас будет стабильное интернет-соединение (это может занять несколько минут).

Не обрабатывайте свои идентификаторы на клиенте

Я знаю, что знаю ... это может сильно расстроить вас, но я бы не рекомендовал создавать идентификаторы для вашего клиента. Прежде всего, клиент никогда не должен решать, как будут вводиться идентификаторы на сервере. Более того, даже если вы используете временные идентификаторы на своем клиенте, вы очень быстро столкнетесь с адом сложности, если будете ссылаться на идентификаторы в своей indexedDB. Представьте, что вы обновляете эти временные идентификаторы идентификаторами, поступающими с сервера… удачи в этом :).

Таким образом, лучший вариант использования фоновой синхронизации - запустить и забыть сообщения.