2015-01-21 4 views
2
  • Кэш всех запросов из приложения без явного указания urlsToCache. Поэтому я буду кэшировать материал под событием fetch.
  • Чтобы отвечать на запросы из кеша.
  • Обновление кеша при успешном извлечении.

ПервоначальноКак и когда мы должны писать в кеш в Service Workers?

this.addEventListener('fetch', function(event) { 
    var fetchReq = event.request.clone(), 
     cacheReq = event.request.clone(); 
    event.respondWith(fetch(fetchReq).then(function(response) { 
     var resp = response.clone(); 
     caches.open(CACHE_NAME).then(function(cache) { 
      req = event.request.clone(); 
      cache.put(req, resp); 
     }); 
     return response; 
    }).catch(function() { 
     return caches.match(cacheReq); 
    })); 
}); 

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

self.addEventListener('fetch', function(event) { 
    var cacheRequest = event.request.clone(); 
    event.respondWith(caches.match(cacheRequest).then(function(response) { 
     if(response) return response; 
     var fetchRequest = event.request.clone(); 
     return fetch(fetchRequest).then(function(response) { 
      var responseToCache = response.clone(); 
      caches.open(cache_name).then(function(cache) { 
       var cacheSaveRequest = event.request.clone(); 
       cache.put(cacheSaveRequest, responseToCache); 
      }); 
      return response; 
     }); 
    })); 
}); 

С приоритетом кеша, ответы, поданные, были прекрасными. Но проблема здесь в том, что когда код обновляется. Когда /public/main.css, обслуживаемый через sw, обновляется, на странице перезагружается только кеш, обновленный контент не обслуживается.

Я также попытался изменениями cache_name к cache-v2 от cache-v1 (так что ЮЗ двоичного дифференциала существует и SW обновляется и старый кэш может быть сброшен) и очищенной cache-v1 на activate событии. Но это породило новые проблемы, когда одновременно работали два сервисных работ под тем же Registration ID. Подробнее об этом в этом другом вопросе SO: How to stop older service workers?

+0

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

ответ

6

Рабочие двух рабочих, работающих в то же время, не являются технически проблемой - он работает как разработанный. (См. Мой ответ на How to stop older service workers?) Убедитесь, что вы закрыли другие вкладки, в которых может быть установлена ​​более старая версия вашего рабочего.

Вы сталкиваетесь с неизбежными компромиссами между различными сценариями кэша и сетью здесь. Если вы еще не прочитали the offline cookbook, это отличная отправная точка при попытке решить, какая стратегия кеширования лучше всего подходит для ваших конкретных ресурсов.

+0

'компромисс между кэшем и сетевыми сценариями' - точно !. Кстати, есть ли предложение добавить кэш TTL. Я мутировал клон Response. например 'response.TTL = new Date() + ttl'; Я предполагаю, что это плохой способ использования. –

+0

У меня нет конкретных рекомендаций по кэшу TTL. Пока этого не делал. Просмотрите https://github.com/jeffposnick/sw-precache пример использования хэшей файлов в качестве способа идентификации при обновлении ресурсов, что представляет собой другой подход. –