Best Practices für die Synchronisierung des Anwendungsstatus zwischen IndexedDB und gängigen Bibliotheken zur Statusverwaltung
Wenn ein Nutzer eine Website oder Anwendung zum ersten Mal lädt, ist es oft ziemlich aufwendig, den ursprünglichen Anwendungsstatus zu erstellen, der zum Rendern der Benutzeroberfläche verwendet wird. Manchmal muss die App den Nutzer beispielsweise clientseitig authentifizieren und dann mehrere API-Anfragen stellen, bevor alle Daten verfügbar sind, die auf der Seite angezeigt werden sollen.
Wenn Sie den Anwendungsstatus in IndexedDB speichern, lässt sich die Ladezeit bei wiederholten Besuchen erheblich beschleunigen. Die App kann sich dann im Hintergrund mit beliebigen API-Diensten synchronisieren und die Benutzeroberfläche mit neuen Daten aktualisieren, indem eine Stale-While-Revalidate-Strategie verwendet wird.
Bei der Verwendung von IndexedDB gibt es jedoch viele wichtige Dinge zu beachten, die für Entwickler, die mit den APIs noch nicht vertraut sind, möglicherweise nicht sofort offensichtlich sind. In diesem Dokument werden häufig gestellte Fragen beantwortet und einige der wichtigsten Dinge erläutert, die Sie beim Speichern des Anwendungsstatus in IndexedDB beachten sollten.
App nutzerfreundlich gestalten
Viele der Komplexitäten von IndexedDB resultieren aus der Tatsache, dass es so viele Faktoren gibt, auf die Sie (der Entwickler) keinen Einfluss haben. In diesem Abschnitt werden viele der Probleme behandelt, die Sie bei der Arbeit mit IndexedDB beachten müssen.
Schreibvorgänge in den Speicher können fehlschlagen
Fehler beim Schreiben in IndexedDB können aus verschiedenen Gründen auftreten. In einigen Fällen liegen diese Gründe außerhalb Ihrer Kontrolle als Entwickler. Beispielsweise erlauben einige Browser das Schreiben in IndexedDB nicht, wenn sich der Nutzer im Inkognitomodus befindet. Es kann auch sein, dass der Nutzer ein Gerät verwendet, auf dem der Speicherplatz fast aufgebraucht ist. In diesem Fall verhindert der Browser das Speichern von Daten.
Daher ist es wichtig, dass Sie in Ihrem IndexedDB-Code immer eine ordnungsgemäße Fehlerbehandlung implementieren. Daher ist es im Allgemeinen eine gute Idee, den Anwendungsstatus nicht nur zu speichern, sondern auch im Arbeitsspeicher zu halten, damit die Benutzeroberfläche nicht zusammenbricht, wenn die App im Inkognitomodus ausgeführt wird oder kein Speicherplatz verfügbar ist (auch wenn einige der anderen App-Funktionen, für die Speicherplatz erforderlich ist, nicht funktionieren).
Gespeicherte Daten wurden möglicherweise vom Nutzer geändert oder gelöscht.
Im Gegensatz zu serverseitigen Datenbanken, bei denen Sie den unbefugten Zugriff einschränken können, sind clientseitige Datenbanken für Browsererweiterungen und Entwicklertools zugänglich und können vom Nutzer gelöscht werden.
Es ist zwar nicht üblich, dass Nutzer ihre lokal gespeicherten Daten ändern, aber es ist durchaus üblich, dass sie sie löschen. Es ist wichtig, dass Ihre Anwendung beide Fälle ohne Fehler bewältigen kann.
Gespeicherte Daten sind möglicherweise veraltet
Ähnlich wie im vorherigen Abschnitt ist es auch möglich, dass die Daten, die der Nutzer gespeichert hat, von einer früheren Version Ihres Codes geschrieben wurden, möglicherweise einer Version mit Fehlern.
IndexedDB bietet integrierte Unterstützung für Schemaversionen und Upgrades mit der Methode IDBOpenDBRequest.onupgradeneeded(). Sie müssen den Upgrade-Code jedoch so schreiben, dass er mit Nutzern umgehen kann, die von einer früheren Version (einschließlich einer Version mit einem Fehler) kommen.
Hier können Unit-Tests sehr hilfreich sein, da es oft nicht möglich ist, alle möglichen Upgradepfade und -fälle manuell zu testen.
App-Leistung aufrechterhalten
Eines der Hauptmerkmale von IndexedDB ist die asynchrone API. Das bedeutet jedoch nicht, dass Sie sich bei der Verwendung keine Gedanken über die Leistung machen müssen. In einigen Fällen kann der Haupt-Thread durch unsachgemäße Nutzung blockiert werden, was zu einer Verzögerung der Reaktion führen kann.
In der Regel sollten Lese- und Schreibvorgänge in IndexedDB nicht größer sein als für die zugegriffenen Daten erforderlich.
Mit IndexedDB können zwar große, verschachtelte Objekte als einzelner Datensatz gespeichert werden, was aus Entwicklersicht durchaus praktisch ist, aber diese Praxis sollte vermieden werden. Der Grund dafür ist, dass IndexedDB beim Speichern eines Objekts zuerst einen strukturierten Klon dieses Objekts erstellen muss. Der Prozess des strukturierten Klonens erfolgt im Hauptthread. Je größer das Objekt, desto länger ist die Blockierungszeit.
Das stellt einige Herausforderungen bei der Planung der Speicherung des Anwendungsstatus in IndexedDB dar, da die meisten gängigen Bibliotheken zur Zustandsverwaltung (z. B. Redux) den gesamten Statusbaum als einzelnes JavaScript-Objekt verwalten.
Das Verwalten des Status auf diese Weise hat viele Vorteile und das Speichern des gesamten Statusbaums als einzelner Datensatz in IndexedDB kann verlockend und praktisch sein. Wenn Sie dies jedoch nach jeder Änderung tun (auch wenn sie gedrosselt oder verzögert wird), führt dies zu unnötigen Blockierungen des Hauptthreads, erhöht die Wahrscheinlichkeit von Schreibfehlern und führt in einigen Fällen sogar dazu, dass der Browsertab abstürzt oder nicht mehr reagiert.
Anstatt den gesamten Statusbaum in einem einzelnen Datensatz zu speichern, sollten Sie ihn in einzelne Datensätze aufteilen und nur die Datensätze aktualisieren, die sich tatsächlich ändern.
Wie bei den meisten Best Practices ist dies keine Regel, die entweder ganz oder gar nicht gilt. Wenn es nicht möglich ist, ein Statusobjekt aufzuteilen und nur das minimale Änderungsset zu schreiben, ist es immer noch besser, die Daten in Unterbäume aufzuteilen und nur diese zu schreiben, als immer den gesamten Statusbaum zu schreiben. Kleine Verbesserungen sind besser als gar keine.
Außerdem sollten Sie immer die Leistungsauswirkungen des von Ihnen geschriebenen Codes messen. Es stimmt zwar, dass kleine Schreibvorgänge in IndexedDB eine bessere Leistung als große Schreibvorgänge erzielen. Das ist aber nur dann wichtig, wenn die Schreibvorgänge in IndexedDB, die von Ihrer Anwendung ausgeführt werden, tatsächlich zu langen Aufgaben führen, die den Hauptthread blockieren und die Nutzerfreundlichkeit beeinträchtigen. Es ist wichtig, die Leistung zu messen, damit Sie wissen, wofür Sie optimieren.
Ergebnisse
Entwickler können Clientspeichermechanismen wie IndexedDB verwenden, um die Nutzerfreundlichkeit ihrer Anwendung zu verbessern. Dazu wird der Status nicht nur über mehrere Sitzungen hinweg beibehalten, sondern auch die Zeit verkürzt, die zum Laden des ursprünglichen Status bei wiederholten Besuchen benötigt wird.
Die korrekte Verwendung von IndexedDB kann die Nutzerfreundlichkeit erheblich verbessern. Eine falsche Verwendung oder das Nichtbeheben von Fehlern kann jedoch zu instabilen Apps und unzufriedenen Nutzern führen.
Da der Clientspeicher viele Faktoren umfasst, die außerhalb Ihrer Kontrolle liegen, ist es wichtig, dass Ihr Code gut getestet ist und Fehler ordnungsgemäß behandelt werden, auch solche, die anfangs unwahrscheinlich erscheinen.