En quoi localStorage est-il différent de indexedDB?
localStorage et indexedDB sont utilisés pour le stockage hors ligne de données en HTML5. Quelles sont leurs principales différences et laquelle est préférable dans quelles situations?
En apparence, les deux technologies peuvent sembler directement comparables, mais si vous passez du temps avec elles, vous vous rendrez vite compte qu'elles ne le sont pas. Ils ont été conçus pour atteindre un objectif similaire, le stockage côté client, mais ils abordent la tâche à accomplir sous des perspectives très différentes et fonctionnent mieux avec différentes quantités de données.
localStorage, ou plus précisément Web Storage , a été conçu pour de plus petites quantités de données. Il s'agit essentiellement d'un chaîne uniquement de stockage clé-valeur , avec un synchrone simpliste synchrone API. Cette dernière partie est essentielle. Bien qu'il n'y ait rien dans la spécification qui interdise un stockage Web asynchrone, actuellement toutes les implémentations sont synchrones (c'est-à-dire les demandes de blocage). Même si cela ne vous dérange pas d'utiliser un stockage de valeur clé naïf pour de plus grandes quantités de données, vos clients ne craindront pas d'attendre indéfiniment le chargement de votre application.
indexedDB , d'autre part, a été conçu pour fonctionner avec des quantités de données beaucoup plus importantes. Premièrement, en théorie, il fournit à la fois une API synchrone et une API asynchrone. En pratique, cependant, toutes les implémentations actuelles sont asynchrones et les requêtes ne bloqueront pas le chargement de l'interface utilisateur. De plus, indexedDB, comme son nom l'indique, fournit indexes . Vous pouvez exécuter des requêtes rudimentaires sur votre base de données et récupérer des enregistrements en recherchant leurs clés dans des plages de clés spécifiques . indexedDB prend également en charge transactions , et fournit des types simples (par exemple Date).
À ce stade, indexedDB peut sembler la solution supérieure pour chaque situation. Cependant, il y a une pénalité pour toutes ses fonctionnalités: par rapport au stockage Web, son API est assez compliquée. indexedDB suppose une familiarité générale avec les concepts de base de données, tandis qu'avec Web Storage, vous pouvez vous lancer directement. Si vous avez déjà travaillé avec des cookies, vous n'aurez aucun problème à travailler avec Web Storage. De plus, en général, vous devrez écrire plus de code dans indexedDB pour obtenir exactement le même résultat que dans Web Storage (et plus de code = plus de bogues). En outre, l'émulation de Web Storage pour les navigateurs qui ne le prennent pas en charge est relativement simple. Avec indexedDB, la tâche ne vaut pas la peine. Enfin, avant de plonger dans indexedDB, vous devez d'abord jeter un œil à Quota API .
À la fin de la journée, c'est à vous de décider si vous utilisez Web Storage ou indexedDB, ou les deux, dans votre application. Un bon cas d'utilisation pour Web Storage serait de stocker des données de session simples, par exemple le nom d'un utilisateur, et de vous enregistrer certaines demandes dans votre base de données réelle. Les fonctionnalités supplémentaires d'indexedDB, d'autre part, pourraient vous aider à stocker toutes les données dont vous avez besoin pour que votre application fonctionne hors ligne.
La réponse de @yannis est excellente. Je veux juste ajouter quelques éléments.
Dans certaines situations, comme Service Workers, vous ne pouvez pas utiliser de code de blocage, par conséquent, vous ne pouvez pas utiliser localStorage et devez utiliser quelque chose comme indexedDB.
L'API pour indexedDB est complexe et fastidieuse (j'irais jusqu'à dire "horrible", YMMV). Il existe plusieurs bibliothèques "wrapper" pour simplifier l'API, je fortement vous suggère de les consulter.
Pour moi, j'ai trouvé que je peux stocker blobs dans IndexedDB tandis que dans localStorage, je ne peux stocker que des chaînes. Cela signifie que IndexdDB est meilleur pour les données binaires comme les images, l'audio, la vidéo. Oui, nous pouvons stocker des images en base64 dans le localStorage, mais les blobs seront plus petits et plus rapides car nous n'avons pas besoin de les décoder.
Citation de MDN :
The keys and the values are always strings.
Any objects supported by the structured clone algorithm can be stored:
All primitive types However not symbols
Boolean object
String object
Date
RegExp The lastIndex field is not preserved.
Blob
File
FileList
ArrayBuffer
ArrayBufferView This basically means all typed arrays like Int32Array etc.
ImageData
Array
Object This just includes plain objects (e.g. from object literals)
Map
Set