`localStorage` n'est pas maléfique. Il est simplement facile à mal utiliser.
Il fonctionne bien pour :
- une préférence de thème
- un petit cache de drapeau de fonctionnalité
- des indications de session légères
Il est mal adapté pour :
- de grands ensembles de données hors ligne
- des systèmes de brouillon avec beaucoup de contenu
- des files d'attente d'opérations synchronisées
- des charges utiles image ou binaire
## La Principale Limitation
L'API est synchrone.
Cela signifie que les lectures et les écritures se produisent sur le thread principal, ce qui est exactement l'endroit où vous ne voulez pas que de gros travaux de stockage se déroulent dans une application moderne.
Pour les petites clés, cela est généralement acceptable. Pour des caches de taille application, cela devient un signe de conception problématique.
## Quand IndexedDB Est le Meilleur Choix
IndexedDB est beaucoup mieux adapté lorsque vous avez besoin de :
- enregistrements structurés
- accès asynchrone
- transactions
- persistance plus importante côté client
C'est pourquoi les applications web sérieuses capables de fonctionner hors ligne finissent souvent par l'utiliser.
L'inconvénient est l'ergonomie. L'API native n'est pas agréable à utiliser directement.
## Pourquoi les Bibliothèques Aident
Des wrappers comme Dexie rendent IndexedDB beaucoup plus facile à considérer comme une partie de l'architecture de l'application plutôt que comme une originalité du navigateur de bas niveau.
```ts
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",
});
Cela suffit souvent à rendre la persistance côté navigateur maintenable.
Une Meilleure Règle Générale
Utilisez :
localStorage pour un état léger semblable à une préférence- IndexedDB pour des données réelles d'application
Cette ligne vous fera éviter beaucoup de douleurs d'architecture frontend.
Lectures Complémentaires