Verwenden Sie `localStorage` für Präferenzen, IndexedDB für Daten_
Die richtige Wahl für den Browser-Speicher hängt von der Arbeitslast ab. `localStorage` eignet sich gut für winzige synchrone Zustände; IndexedDB ist besser geeignet für Offline-Daten und größere Caches.
localStorage ist nicht böse. Es ist nur leicht missbrauchbar.
Es funktioniert gut für:
eine Themenpräferenz
einen kleinen Feature-Flag-Cache
leichte Sitzungshinweise
Es ist schlecht geeignet für:
große Offline-Datensätze
Entwurfssysteme mit vielen Inhalten
Warteschlangen von Synchronisationsoperationen
Bilder oder binäre Nutzlasten
Die Hauptbeschränkung
Die API ist synchron.
Das bedeutet, dass Lese- und Schreibvorgänge im Hauptthread stattfinden, was genau der Ort ist, an dem Sie in einer modernen App keine umfangreichen Speicheroperationen haben möchten.
Für kleine Schlüssel ist das normalerweise in Ordnung. Für anwendungsgrößere Caches wird es jedoch zu einem Design-Geruch.
Wann IndexedDB die bessere Wahl ist
IndexedDB ist ein viel besseres Passstück, wenn Sie benötigen:
strukturierte Datensätze
asynchronen Zugriff
Transaktionen
größere clientseitige Persistenz
Das ist der Grund, warum ernsthafte webfähige Offline-Apps schließlich meistens dort enden.
Der Nachteil ist die Ergonomie. Die native API ist nicht angenehm direkt zu verwenden.
Warum Bibliotheken helfen
Wrapper wie Dexie machen es viel einfacher, IndexedDB als Teil der Anwendungsarchitektur zu behandeln, anstatt als niedrigrangige Browser-Eigenart.
import Dexie, { type EntityTable } from "dexie";interface Draft { id: number; title: string; body: string;}const db = new Dexie("writer") as Dexie & { drafts: EntityTable<Draft, "id">;};db.version(1).stores({ drafts: "++id, title",});
Das ist oft genug, um die browserseitige Persistenz wartbar zu machen.
Eine bessere Faustregel
Verwenden Sie:
localStorage für winzige zustandsähnliche Präferenzen
IndexedDB für echte Anwendungsdaten
Diese Linie wird viel Schmerz bei der Frontend-Architektur ersparen.