localStorage e indexedDB vengono utilizzati per l'archiviazione offline dei dati in HTML5. Quali sono le loro differenze chiave e quale è preferibile in quali situazioni?
In apparenza le due tecnologie possono sembrare direttamente comparabili, tuttavia se passi un po 'di tempo con loro ti renderai presto conto che non lo sono. Sono stati progettati per raggiungere un obiettivo simile, l'archiviazione lato client, ma si avvicinano al compito in corso da prospettive significativamente diverse e funzionano meglio con diverse quantità di dati.
localStorage, o più esattamente Archiviazione Web , è stato progettato per piccole quantità di dati. È essenzialmente una stringhe di valori-chiave solo , con un'API sincrona semplicistica. L'ultima parte è la chiave. Sebbene non vi sia nulla nelle specifiche che vieti uno storage DOM asincrono, attualmente tutte le implementazioni sono sincrone (cioè richieste di blocco). Anche se non ti dispiace usare una chiave ingenua - memoria di valore per grandi quantità di dati, i tuoi clienti non vedranno l'ora di aspettare il caricamento dell'applicazione.
indexedDB , d'altra parte, è stato progettato per funzionare con quantità significativamente maggiori di dati. In primo luogo, in teoria, fornisce sia un'API sincrona sia un'asincrona. In pratica, tuttavia, tutte le implementazioni correnti sono asincrone e le richieste non impediranno il caricamento dell'interfaccia utente. Inoltre, indexedDB, come rivela il nome, fornisce indici . Puoi eseguire query rudimentali sul tuo database e recuperare i record cercando le loro chiavi in specifiche intervalli di tasti . indexedDB supporta anche le transazioni e fornisce tipi semplici (ad es. Date).
A questo punto, indexedDB potrebbe sembrare la soluzione migliore per ogni situazione. Tuttavia, c'è una penalità per tutte le sue caratteristiche: rispetto a DOM Storage, la sua API è piuttosto complicata. indexedDB presuppone una generale familiarità con i concetti del database, mentre con DOM Storage puoi saltare direttamente dentro. Se hai mai lavorato con i cookie, non avrai problemi con il DOM Storage. Inoltre, in generale, dovrai scrivere più codice in indexedDB per ottenere esattamente lo stesso risultato di DOM Storage (e più codice = più bug). Inoltre, l'emulazione di DOM Storage per i browser che non la supportano è relativamente semplice. Con indexedDB, l'attività non varrebbe la pena. Infine, prima di immergerti in indexedDB, dovresti prima dare un'occhiata alla API di quota .
Alla fine della giornata, dipende completamente da te se usi DOM Storage o indexedDB, o entrambi, nella tua applicazione. Un buon caso d'uso per DOM Storage sarebbe quello di memorizzare semplici dati di sessione, ad esempio il nome di un utente, e salvare alcune richieste al proprio database. Le funzionalità aggiuntive di indexedDB, d'altra parte, potrebbero aiutarti a memorizzare tutti i dati necessari per far funzionare la tua applicazione offline.
la risposta di @annis è eccellente. Voglio solo aggiungere un paio di cose.
In alcune situazioni, come i lavoratori del servizio, non è possibile utilizzare il codice di blocco, quindi, non è possibile utilizzare localStorage e deve utilizzare qualcosa come indexedDB.
L'API per indexedDB è complessa e noiosa (direi "orribile", YMMV). Esistono diverse librerie "wrapper" per semplificare l'API, io strongmente ti suggerisco di guardarle.
Per quanto mi riguarda, ho scoperto che posso memorizzare blob in IndexedDB mentre in localStorage posso memorizzare solo le stringhe. Significa che IndexdDB è migliore per dati binari come immagini, audio, video. Sì, possiamo archiviare le immagini in base64 nel localStorage, ma i BLOB saranno più piccoli e più veloci perché non è necessario decodificarli.
Citazione da 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