Должен ли работник сервиса быть зарегистрирован в манифесте или через скрипт? - PullRequest
0 голосов
/ 12 мая 2018

Большинство примеров регистрации работника Службы делают это через JavaScript. Например (от MDN ):

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('service-worker.js', {
    scope: './'
  }).then(function (registration) {
    var serviceWorker;
    if (registration.installing) {
      serviceWorker = registration.installing;
      document.querySelector('#kind').textContent = 'installing';
    } else if (registration.waiting) {
      serviceWorker = registration.waiting;
      document.querySelector('#kind').textContent = 'waiting';
    } else if (registration.active) {
      serviceWorker = registration.active;
      document.querySelector('#kind').textContent = 'active';
    }
    if (serviceWorker) {
      // logState(serviceWorker.state);
      serviceWorker.addEventListener('statechange', function (e) {
        // logState(e.target.state);
      });
    }
  }).catch (function (error) {
    // Something went wrong during registration. The service-worker.js file
    // might be unavailable or contain a syntax error.
  });
} else {
  // The current browser doesn't support service workers.
}

Но в стандарте Web App Manifest я заметил, что существует serviceworker член:

"serviceworker": {
  "src": "sw.js",
  "scope": "/",
  "update_via_cache": "none"
}

Это единственное место, где я видел это упомянутое.

Это вызывает у меня два вопроса:

1 Какой подход СЛЕДУЕТ использовать? Каковы компромиссы?

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

Предполагая, что можно правильно ссылаться на объект регистрации, он может пропустить события? Например, завершить установку, прежде чем я смогу зарегистрировать прослушиватель событий.

2 Каковы последствия кэширования

Поскольку манифест будет сохранен в автономном кэше, и этот манифест будет ссылаться на сценарий работника службы, каковы последствия кеша? Действует ли правило 24 часа, если я НЕ храню сценарий в автономном кэше? Элемент update_via_cache не прост для чтения в спецификации.

1 Ответ

0 голосов
/ 16 мая 2018

Похоже, что он был добавлен в спецификацию еще в октябре 2016 года , и в системе отслеживания проблем .

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

Итак ... на данный момент, я не уверен, что какие-либо браузеры уважаютserviceworker поле в манифесте веб-приложения, и если ваша проблема заключается в регистрации работника функционального сервиса для сценариев использования в «браузере», сделайте это с помощью JavaScript.

Лучшим вариантом для последующих проверок будет запрос на средство отслеживания проблем GitHub в манифесте веб-приложения .

...