Für ServiceWorker cache.addAll(), wie funktionieren die URLs?

Question

Ich sehe eine Menge von Beispielcode wie folgt aus: (Ein wenig gekürzte Version this Mozilla Doc)

this.addEventListener('install', function(event) { 
    event.waitUntil(
    caches.open('v1').then(function(cache) { 
     return cache.addAll([ 
     '/sw-test/', 
     '/sw-test/index.html', 
     '/sw-test/style.css', 
     '/sw-test/gallery/', 
     '/sw-test/gallery/bountyHunters.jpg', 
     ]); 
    }) 
); 
}); 

Ich verstehe nicht, warum Sie beide /sw-test/und/sw-test/index.html hinzuzufügen. Es scheint so, als würde entweder die erste Ordner-URL automatisch alles darunterladen oder, wenn es das nicht tut, warum ist es dort? Gleiches für /sw-test/gallery/ und /sw-test/gallery/bountyHunters.jpg.

Die Dokumente sagen "Die addAll() - Methode der Cache-Schnittstelle nimmt ein Array von URLs, ruft sie ab und fügt die resultierenden Antwortobjekte dem angegebenen Cache hinzu". Was nicht sehr hilfreich ist.

Ich möchte wirklich alle * .html-Dateien aus ein paar Ordnern und allen Bilddateien (in verschiedenen Formaten) aus einem anderen Ordner zwischenspeichern. Sie einzeln aufzulisten, ist zerbrechlich (wird schnell außer Kontrolle geraten), neigt zu Tippfehlern und ist einfach nur albern.

Nach einer weiteren Lesung später hinzugefügt, scheint nicht, wie Platzhalter vorhanden sind, so albern es ist. :-) Aber was ist der Punkt des Hinzufügens eines Ordners wie /sw-test/?

Answer 1

Ja, ein Platzhalter existiert nicht und das ist eigentlich völlig in Ordnung, wenn Sie darüber nachdenken: Der Webserver stellt die in einem Pfad gefundenen Dateien nicht zur Verfügung (zB./Gallery /) also wie könnte der Browser Cache-Dateien, für die die Namen nicht bekannt sind? Ein Webserver kann natürlich so konfiguriert werden, dass er die Verzeichnislisten eines Pfades freilegt, aber die Browser selbst haben keine Möglichkeit, "alles von diesem Pfad x zu übernehmen". Die Verzeichnis-/Indexliste ist nur ein Haufen HTML, keine Zuordnung von Dateien oder so.

Caching sowohl/und /index.html ist ein wenig verwirrend, aber vom Standpunkt des Service Worker aus betrachtet, sind sie unterschiedliche URLs. Der Webserver ist normalerweise so konfiguriert, dass er dieselbe Datei (index.html) anbietet, egal welche URL Sie besuchen, aber wenn Sie die SW fragen, sind sie getrennt und sollten separate Einträge im Cache haben. Dies kann leicht getestet werden: deploy etwas, das die/aber nicht /index.html zwischenspeichert (obwohl der Webserver index.html aus/bedient) und versuchen, /index.html im Offline-Modus zu besuchen. Kein Glück.

Ich glaube nicht, dass es überhaupt einen Grund gibt, /index.html zu cachen, wenn Sie absolut sicher sind, dass Ihre Web-App keine Anfragen daran stellt. Wenn Ihre Web-App nur weiß/dann verlassen/index.html sollte völlig in Ordnung sein. Ich habe das selbst getestet und es funktioniert perfekt. Wenn jemand mehr Informationen zu diesem Thema hat, korrigiere mich bitte!

Etwas zu beachten könnte nützlich sein: Die SW kann so konfiguriert werden, dass sie/und/index.html als gleich behandelt. Es ist also möglich, Caching/und Serving immer dann durchzuführen, wenn eine der beiden angefordert wird. Ich denke, einige Bibliotheken haben diese Art von Funktionalität eingebaut.

Answer 2

Aufbauend auf der obigen Antwort von pate: sw-precache und sw-toolbox sind zwei Bibliotheken, die bei der Implementierung von Service Workern häufig empfohlen werden, da sie diese Platzhalterfunktionalität ermöglichen.