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.
Weiterführende Literatur