Speichern von Daten auf dem Gerät

  • Artikel

Progressive Web-Apps (PWA) bieten robuste Optionen zum lokalen Speichern von Daten, damit Benutzer weiterhin arbeiten können, auch wenn die Netzwerkverbindung instabil wird oder offline geschaltet wird.

Es gibt mehrere Möglichkeiten, wie eine PWA Daten auf einem Gerät speichern kann, z. B. lokaler Speicher, Cache-API oder IndexedDB.

In der folgenden Tabelle werden die verschiedenen Optionen beschrieben, und der Rest dieses Artikels enthält weitere Details und Verwendungsszenarien für jede Option.

Speicheroption Beschreibung
Webspeicher Webspeicher verfügt über zwei Typen: sitzungsbasierte und lokale Speicher. Webspeicher ist nützlich, um kleine Datenmengen aus dem Front-End-Code Ihrer App zu speichern. Die Daten sind als Schlüssel-Wert-Paare strukturiert und nur für den aktuellen App-Ursprung verfügbar. Im Fall des Sitzungsspeichers werden die Daten gelöscht, wenn die Sitzung endet, z. B. wenn die App geschlossen wird, oder wenn der Benutzer zu einem anderen Ursprung im selben Fenster oder auf der gleichen Registerkarte navige. Der lokale Speicher bleibt erhalten, bis die App die Daten entfernt.
Indexeddb IndexedDB ist eine API zum Speichern größerer Mengen strukturierter Daten. Die API ist asynchron und kann sowohl vom Front-End-Code Ihrer App als auch vom Service Worker-Code verwendet werden. Verwenden Sie die IndexedDB-API, um eine erhebliche Menge strukturierter Daten oder Binärdaten wie verschlüsselte Medienobjekte oder Dateien auf dem Client zu speichern.
Cache Die Cache-API kann verwendet werden, um zwischengespeicherte Ressourcen zu verwalten. Die Cache-API basiert auf Zusage und ermöglicht Entwicklern das Speichern und Abrufen vieler Webressourcen – HTML, CSS, JavaScript, Bilder, JSON usw. In der Regel wird die Cache-API im Kontext eines Service Workers verwendet, ist aber auch für den Front-End-Code Ihrer App verfügbar.
Dateisystemzugriff Die Dateisystemzugriffs-API ermöglicht es Ihrer PWA, Dateien und Ordner auf dem Gerät des Benutzers zu lesen und Änderungen daran zurückzuspeichern.

Hinweis: Verwenden Sie nicht WebSQL oder Anwendungscache. Dies sind zwar zwei weitere Browserspeichermechanismen, beide sind jedoch veraltet. Verwenden Sie anstelle von WebSQL IndexedDB. Verwenden Sie anstelle des Anwendungscaches die Cache-API.

Webspeicher

Webspeicher ist nützlich, um kleine Mengen von Zeichenfolgendaten auf dem Gerät des Benutzers zu speichern. Die Einfachheit des Schlüssel-Wert-Paarsystems von Web Storage macht es einfach zu verwenden.

Webspeicher funktioniert nur synchron im Hauptthread Ihrer App. Dies bedeutet, dass Webspeicher nicht für die Verwendung innerhalb von Service Workern verfügbar ist und dass eine starke Nutzung von Webspeicher zu Leistungsproblemen für Ihre Anwendung führen kann.

Jeder Webspeichertyp (Sitzung und lokal) wird als separater Datenspeicher verwaltet, der von der Domäne isoliert ist, von der er erstellt wurde.

  • sessionStorage Wird nur für die Dauer der Sitzung beibehalten, z. B. während der Browser geöffnet ist, einschließlich der Aktualisierung der Seite.
  • localStorage wird beibehalten, bis die Daten vom App-Code, vom Benutzer oder vom Browser entfernt werden.

Der folgende Code zeigt, wie verwendet localStoragewird. Dies ähnelt der sessionStorage Verwendung:

const browserInformation = {
  name: 'Microsoft Edge',
  version: 108
};

localStorage.setItem('browser', JSON.stringify(browserInformation));

Der obige Code speichert ein JavaScript-Objekt als JSON-Zeichenfolge in localStorage mithilfe der setItem() -Methode und weist einen Schlüssel zu browser. Sie können die Informationen aus localStorage abrufen, indem Sie die getItem() -Methode wie unten gezeigt verwenden:

const value = localStorage.getItem('browser');

const browserInformation = JSON.parse(value);

Weitere Informationen finden Sie unter Web Storage-API in MDN.

Indexeddb

IndexedDB ist eine asynchrone API zum Speichern strukturierter Daten, die im Front-End- oder Service Worker-Code Ihrer App verwendet werden können. Verwenden Sie die IndexedDB-API zum Speichern einer erheblichen Menge strukturierter Daten auf dem Client oder binärdaten, z. B. verschlüsselte Medienobjekte oder Dateien.

IndexedDB ist die beste Option zum Speichern von Daten in Ihrer PWA, da die Verwendung der API Ihre App nicht verlangsamt, indem der Hauptthread blockiert wird und sowohl vom Front-End-Code Ihrer App als auch vom Service Worker verwendet werden kann.

Die Verwendung von IndexedDB ist komplexer als die Verwendung von Webspeicher und erfordert die folgenden Schritte zum Speichern von Daten:

  1. Öffnen Sie mithilfe der window.indexedDB.open() -Funktion eine Datenbank.
  2. Erstellen Sie mithilfe der -Funktion einen Objektspeicher in der IDBDatabase.createObjectStore() Datenbank.
  3. Starten Sie eine Transaktion zum Speichern von Daten mithilfe der IDBDatabase.transaction() -Funktion.
  4. Warten Sie, bis der Vorgang abgeschlossen ist, indem Sie auf ein Ereignis lauschen.

Weitere Informationen und Codebeispiele finden Sie unter Verwenden von IndexedDB in MDN.

Cache

Die Cache-API ist ein System zum Speichern und Abrufen von Netzwerkanforderungen und -antworten im Front-End-Code oder Service Worker Ihrer App. Es kann verwendet werden, um Ressourcen wie Bilder und Dateien lokal auf dem Gerät des Benutzers zu speichern. Dies kann dazu führen, dass Ihre Anwendung funktioniert, auch wenn sie offline ist, oder die Leistung verbessern, indem die Anzahl der Netzwerkanforderungen reduziert wird, die zum Rendern der App erforderlich sind.

Der folgende Codeausschnitt zeigt, wie Sie das fetch Ereignis in einem Service Worker lauschen und die Antwort vom Server mithilfe der Cache-API speichern:

self.addEventListener("fetch", event => {
  async function cacheAndReturnRequest() {
    // Get the response from the server.
    const fetchResponse = await fetch(event.request.url);
    // Open the app's cache.
    const cache = await caches.open("cache-name");
    // Put the response in cache.
    cache.put(event.request.url, fetchResponse.clone());
    // And return the response.
    return fetchResponse.
  }

  event.respondWith(cacheAndReturnRequest());
});

Weitere nützliche Cache-API-Szenarien finden Sie unter Verwenden von Service Workern zum Verwalten von Netzwerkanforderungen.

Dateisystemzugriff

Die Dateisystemzugriffs-API ermöglicht es Ihrer App, auf Dateien auf dem Gerät des Benutzers auf eine Weise zuzugreifen, die nativen Anwendungen ähnelt. Es kann verwendet werden, um Anwendungen zu erstellen, die Dateien lesen und schreiben können, z. B. Text- oder Bild-Editoren.

Verwenden Sie die showOpenFilePicker() -Funktion, um eine Datei auf dem Gerät des Benutzers zu öffnen:

openFileButton.addEventListener("click", async () => {
  const fileHandles = await window.showOpenFilePicker();
});

Weitere Informationen finden Sie unter Window.showOpenFilePicker() auf MDN.

Die Dateisystemzugriffs-API kann auch mit der PWA-Dateibehandlungsfunktion gekoppelt werden, um Ihre App als Handler bestimmter Dateitypen zu registrieren und daher für Benutzer nativ zu sein. Weitere Informationen finden Sie unter Verarbeiten von Dateien in progressiven Web-Apps.

Die API für den zugriff auf das private Dateisystem ist eine Variante der Dateisystemzugriffs-API, die benutzern mehr Datenschutz bieten soll. Es ermöglicht Anwendungen auch den Zugriff auf Dateien auf dem Gerät des Benutzers, jedoch nur innerhalb eines bestimmten Verzeichnisses, das für den Ursprung der App privat ist. Außerdem soll diese API benutzern nicht den Zugriff auf das private Verzeichnis mithilfe ihres Datei-Explorers erleichtern.

Um eine Datei aus dem ursprünglichen privaten Dateisystem zu öffnen, verwenden Sie die navigator.storage Zusage-basierte API:

// Get the origin-private directory handle.
const root = await navigator.storage.getDirectory();
// Get the handle for a file in the directory.
const fileHandle = await root.getFileHandle("my-file.txt");

Speicherkontingent

In Microsoft Edge sind der lokale Speicher und der Sitzungsspeicher auf jeweils ca. 5 MB beschränkt.

Andere Arten von Datenspeichern, z. B. IndexedDB, Cache-API oder Origin Private File System Access API, können bis zu 60 % des gesamten Speicherplatzes auf dem Gerät verbrauchen. Wenn das Gerät, auf dem Ihre App ausgeführt wird, beispielsweise über einen 64-GB-Datenträger verfügt, ermöglicht Microsoft Edge Ihrer App das Speichern von bis zu 38 GB Daten.

Beachten Sie, dass der freie Speicherplatz, der tatsächlich auf dem Gerät verfügbar ist, kleiner als das Speicherkontingent von 60 % sein kann. Wenn das Gerät, auf dem Ihre App ausgeführt wird, beispielsweise über einen 64-GB-Datenträger verfügt, aber bereits 50 GB vom Betriebssystem und anderen Dateien verwendet werden, kann Ihre App nur 14 GB Daten speichern, selbst wenn das Speicherkontingent immer noch 38 GB beträgt.

Sie können verwenden navigator.storage.estimate() , um die Storage Manager-API zu fragen, wie das Speicherkontingent für den Ursprung Ihrer App ist und wie viel davon bereits verwendet wird. Weitere Informationen finden Sie unter StorageManager.estimate() auf MDN.

Der Versuch, mehr Daten zu speichern, als verfügbar oder zulässig sind, führt zu einem JavaScript-Fehler. Ihr Code sollte diesen Fehler mithilfe try...catch von -Anweisungen abfangen. Der folgende Codeausschnitt zeigt, wie Sie beim Speichern von Daten mithilfe von Webspeicher einen Fehler aufgrund eines überschrittenen Kontingents abfangen:

try {
  localStorage.setItem('foo', 'bar');
} catch (e) {
  // Code that handles the lack of storage space.
}

Datenentfernung

Wenn der verfügbare Speicherplatz auf dem Gerät des Benutzers knapp wird(auch als Speicherauslastung bezeichnet), beginnt Microsoft Edge mit dem Entfernen nicht persistenter Daten.

Dies bedeutet, dass die Daten, die Ihre App mit der Cache-API, IndexedDB, der Origin Private File System Access-API oder Webspeicher gespeichert hat, möglicherweise entfernt werden.

Standardmäßig gelten die daten, die Ihre App speichert, nicht als persistent und können entfernt werden, wenn speicherauslastung besteht. Wenn Ihre App kritische Daten speichert, verwenden Sie die -Funktion, um den navigator.storage.persist() Speicher Ihrer App persistent zu gestalten. Persistenter Speicher kann nur vom Benutzer gelöscht werden. Weitere Informationen finden Sie unter StorageManager.persist() auf MDN.