Es gibt nicht viele Beispiele, die indexedDB in einem ServiceWorker demonstrieren, aber die, die ich gesehen habe, waren alle folgendermaßen strukturiert:
%Vor%Scheitert dies wahrscheinlich, wenn der ServiceWorker gestartet wird, und wenn ja, was ist ein robuster Weg für den Zugriff auf indexedDB in einem ServiceWorker?
Das Öffnen des IDB bei jedem Start des ServiceWorker ist wahrscheinlich nicht optimal, Sie öffnen ihn jedoch auch, wenn er nicht benutzt wird. Öffnen Sie stattdessen die Datenbank, wenn Sie sie benötigen. Ein Singleton ist hier wirklich nützlich (siehe Ссылка ), also Sie müssen IDB nicht zweimal öffnen, wenn es während seiner Lebensdauer zweimal verwendet wird.
Das "activate" -Ereignis ist ein großartiger Ort, um IDB zu öffnen und alle "onupdateneded" -Ereignisse laufen zu lassen, da die alte Version von ServiceWorker nicht im Weg ist.
Sie können eine Transaktion wie folgt in ein Versprechen einfügen:
%Vor% Jetzt wird p auflösen / ablehnen, wenn die Transaktion abgeschlossen ist / abbricht. Sie können also beliebige Logik in der tx Transaktion und p.then(...) ausführen und / oder eine abhängige Versprechung in e.respondWith() oder e.waitUntil() etc.
Wie von anderen Kommentatoren bemerkt, müssen wir IndizierteDB wirklich promitrisieren. Aber die Zusammensetzung seines Post-Task-Autocommit-Modells und der Mikrotask-Warteschlangen, die Promises verwenden, machen es ... untrivial, dies zu tun, ohne die API im Wesentlichen vollständig zu ersetzen. Aber (als ein Implementierer und einer der Spezifikationsredakteure) entwickle ich aktiv einige Ideen.
Ich weiß nichts Besonderes über den Zugriff auf IndexedDB aus dem Kontext eines Service-Arbeiters durch Zugriff auf IndexedDB über eine kontrollierte Seite.
Versprechungen machen Ihr Leben innerhalb eines Service-Mitarbeiters offensichtlich viel einfacher, also habe ich z. B. Ссылка um anstelle der rohen IndexedDB-API nützlich zu sein. Es ist jedoch nicht obligatorisch, solange Sie Ihre eigenen Versprechen erstellen und verwalten, um den Status der asynchronen IndexedDB-Vorgänge widerzuspiegeln.
Wenn Sie einen fetch Event-Handler schreiben (und dies ist nicht spezifisch für die Verwendung von IndexedDB), beachten Sie, dass Sie, wenn Sie event.respondWith() aufrufen, entweder ein Response -Objekt übergeben müssen oder ein Versprechen, das mit einem Response -Objekt aufgelöst wird. Solange Sie dies tun, sollte es egal sein, ob Ihr Response aus IndexedDB-Einträgen oder der Cache-API oder anderswo erstellt wird.
Haben Sie irgendwelche Probleme mit dem Code, den Sie gepostet haben, oder war das eher eine theoretische Frage?
Tags und Links html5 service-worker indexeddb