• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Frage Query-String beim Cache-Manifest, Alternativen

Aaron3219

Senior HTML'ler
Hallo liebes Forum,

die Frage steht ja eigentlich schon im Titel:
Da GET-Parameter beim Manifest nicht funktionieren, suche ich nach Alternativen.
Alternativen, die genau so einfach auszulesen sind wie GET-Parameter.
Curl-Methoden z.B., scheinen mir bei weitem nicht so einfach wie ein einfacher Query-String.

Ich bedanke mich für alle Antworten.
 
Werbung:
Ja... da kann ich schwer was gegen sagen. Ich finde halt Application Cache so einfach zu handeln. Aber es bringt halt seine Probleme mit sich und:
ist ohnehin veraltet.

Ich habe schon vorher mit Service-Workern gearbeitet. Aber ich krieg hier irgendwas nicht gebacken.
In meiner index-Datei habe ich folgendes Script:
Javascript:
<script>
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker
      .register('/js/sw.js')
      .then(function() {
        console.log("Service Worker Registered");
      });
  }
</script>
Funktioniert alles einwandfrei. Kein Error. Ich kann den service-worker in den dev-Tools sehen.

Meine sw.js sieht folgendermaßen aus:
Javascript:
importScripts('/mobile-firebase/js/serviceworker-cache-polyfill.js');


self.addEventListener('install', function (e) {
    console.log("fired"); //Dieses console.log ist nur dafür da, um zu sehen, ob das event überhaupt getriggert wurde.
    e.waitUntil(
            caches.open('NexoScanner').then(function (cache) {
        return cache.addAll([
            //Hier meine ganzen Pfade zu den Dateien
        ]);
    }));
});

self.addEventListener('fetch', function (event) {
    console.log(event.request.url);

    event.respondWith(
            caches.match(event.request).then(function (response) {
        return response || fetch(event.request);
    })
            );
});

console.log("fired"); feuert er nur dann, wenn der service-Worker das erste mal installiert wird.

Aber
self.addEventListener('fetch', function (event) {});
triggert nie.
Ich kriege aber auch keine Error-Message.
Dabei sollte er doch eigentlich (zumindest wenn der Browser offline ist) die requests aus dem cache nehmen, sofern sie verfügbar sind...

Wo ist hier mein Fehler???
Die Seiten sind übrigens auch im Cache zu sehen. Sie werden halt nur nicht geladen.
 
Zuletzt bearbeitet:
Werbung:
Guess what:
Das habe ich schon :D

Da alles schon eine Weile her ist, habe ich den meisten Code daher übernommen und wenn man sich das Tutorial genau anschaut, ist der meiste Code sogar identisch.

Btw:
Ich kriege auch kein Callback wenn die ServiceWorker ready sind:
Javascript:
navigator.serviceWorker.ready.then(function (registration) {
    console.log('Service Worker Ready');
});
 
Zuletzt bearbeitet:
Und es wird noch komischer...
Rufe ich das Script im Browser auf
http://localhost/js/sw.js
triggern auf einmal alle events in der Konsole und ich kann mir die Datei auch offline anschauen. Aber auch nur diese Datei, sonst nichts.
Lösche ich sie aus dem Cache, geht es natürlich nicht mehr...
Ich bin verwirrt.
 
Werbung:
Dann stimmt wahrscheinlich irgend etwas mit deinem Code nicht.

Ich baue gerade einen Client für Push-Notifications. Angefangen habe ich auch mit dem Google-Tutorial und das anschließend abgewandelt und ausgebaut. Funktioniert problemlos.
 
Dann stimmt wahrscheinlich irgend etwas mit deinem Code nicht.
Ja, aber nicht mit meinem sw-Code. Ich habe eine einfache Testumgebung aufgebaut und alle Events triggern und ich kann auch die Seite offline verwenden...
Dann muss ich wohl mal schauen woran es liegt.

Edit:
Naja falls das unmöglich sein sollte, suche ich eher nach Alternativen um Daten an die nächste Seite weiterzugeben, die möglichst genauso einfach ist wie ein query-String.
 
Zuletzt bearbeitet:
Okay, Problem gelöst. Die sw.js Datei muss ins root-Verzeichnis.
Um nochmal zurück zur alten Frage zu kommen:
Da GET-Parameter beim Manifest nicht funktionieren, suche ich nach Alternativen.
Eine Alternative habe ich ja jetzt: Service Worker.
Aber auch die funktionieren nicht mit URL-Parametern, sofern ich sie nicht spezifisch cache.
 
Zuletzt bearbeitet:
Werbung:
URL-Parameter sind auch kein guter Ansatz. Du solltest den Request an einen REST-Endpoint senden, der die Datenbank-Abfrage als JSON liefert.
 
Zurück
Oben