La Web Storage API, introdotta con HTML5, ha rivoluzionato il modo in cui le applicazioni web possono memorizzare dati sul browser dell’utente. Prima della sua introduzione, l’unico meccanismo disponibile erano i cookie, con le loro limitazioni di dimensione (circa 4KB) e il sovraccarico di rete causato dall’invio automatico ad ogni richiesta HTTP. localStorage e sessionStorage offrono una soluzione moderna, più capiente e più efficiente per l’archiviazione lato client.
localStorage vs sessionStorage: Le Differenze Fondamentali
La Web Storage API fornisce due meccanismi di archiviazione che condividono la stessa interfaccia ma differiscono significativamente nel comportamento di persistenza. Comprendere queste differenze è fondamentale per scegliere il meccanismo appropriato per ogni caso d’uso.
localStorage memorizza i dati senza scadenza temporale. I dati persistono anche dopo la chiusura del browser e il riavvio del computer, rimanendo disponibili indefinitamente fino a quando non vengono esplicitamente cancellati dal codice JavaScript, dall’utente attraverso le impostazioni del browser, o dal browser stesso in caso di necessità di liberare spazio (cosa che avviene raramente).
sessionStorage memorizza i dati solo per la durata della sessione della scheda del browser. Quando l’utente chiude la scheda (non il browser, ma la specifica scheda), i dati vengono eliminati. Ogni scheda ha il proprio spazio sessionStorage indipendente, anche se puntano allo stesso sito web. Questo isolamento rende sessionStorage ideale per dati temporanei che non devono essere condivisi tra schede diverse.
Entrambi i meccanismi sono vincolati alla same-origin policy: i dati sono accessibili solo da pagine con lo stesso protocollo, dominio e porta. Questo significa che https://example.com e http://example.com hanno spazi di storage separati, così come example.com e sub.example.com.
Confronto con i Cookie
Per comprendere appieno il valore della Web Storage API, è utile confrontarla con i cookie, il meccanismo di storage più antico del web:
- Capacità: i cookie sono limitati a circa 4KB per dominio, mentre Web Storage offre tipicamente 5-10MB per origine
- Traffico di rete: i cookie vengono inviati automaticamente con ogni richiesta HTTP al server, aumentando il traffico; Web Storage è puramente lato client e non viene mai inviato automaticamente
- Scadenza: i cookie possono avere una data di scadenza configurabile; localStorage non scade, sessionStorage dura quanto la scheda
- Accesso server: i cookie sono accessibili sia dal client che dal server; Web Storage è accessibile solo tramite JavaScript lato client
- API: i cookie hanno un’API primitiva basata su stringhe; Web Storage offre un’API moderna e intuitiva
In generale, Web Storage è preferibile per dati che non devono essere inviati al server, come preferenze dell’interfaccia utente, dati di form temporanei e stato dell’applicazione. I cookie rimangono necessari per l’autenticazione basata su sessioni, il tracciamento e qualsiasi dato che il server deve leggere ad ogni richiesta.
Metodi dell’API: setItem, getItem, removeItem e clear
L’interfaccia di Web Storage è elegante nella sua semplicità. Entrambi gli oggetti localStorage e sessionStorage espongono gli stessi quattro metodi principali, oltre a una proprietà length e un metodo key().
Il metodo setItem(chiave, valore) memorizza un dato associandolo a una chiave. Sia la chiave che il valore devono essere stringhe; se si passa un valore non stringa, viene automaticamente convertito tramite toString(). Questo è un punto cruciale: oggetti e array non vengono serializzati automaticamente e devono essere convertiti manualmente con JSON.stringify().
Il metodo getItem(chiave) restituisce il valore associato alla chiave specificata, o null se la chiave non esiste. Per i dati serializzati con JSON.stringify(), è necessario utilizzare JSON.parse() per ricostruire l’oggetto originale. È buona pratica gestire il caso in cui getItem restituisca null, soprattutto quando l’utente visita il sito per la prima volta.
Il metodo removeItem(chiave) rimuove l’elemento associato alla chiave specificata. Se la chiave non esiste, il metodo non genera errori, semplicemente non fa nulla. Il metodo clear() rimuove tutti gli elementi dallo storage dell’origine corrente. La proprietà length restituisce il numero di elementi memorizzati, e il metodo key(indice) restituisce il nome della chiave alla posizione specificata.
È anche possibile accedere ai dati usando la sintassi a parentesi quadre (localStorage[‘chiave’]) o la notazione punto (localStorage.chiave), ma i metodi dell’API sono preferibili per chiarezza del codice e per evitare conflitti con le proprietà native dell’oggetto Storage.
Serializzazione JSON per Dati Complessi
Una delle limitazioni più importanti di Web Storage è che memorizza solo stringhe. Per salvare oggetti JavaScript, array o altri tipi di dati complessi, è necessario serializzarli in formato JSON. Questo processo coinvolge due funzioni fondamentali: JSON.stringify() per la serializzazione (salvataggio) e JSON.parse() per la deserializzazione (lettura).
Un pattern comune prevede la creazione di funzioni helper che incapsulano la logica di serializzazione, gestendo automaticamente la conversione JSON e i possibili errori di parsing. Questo approccio rende il codice più pulito e protegge da errori quando i dati memorizzati sono corrotti o non nel formato atteso.
È importante ricordare che JSON.stringify() non gestisce tutti i tipi JavaScript: le funzioni, i valori undefined, i Symbol e i riferimenti circolari vengono omessi o causano errori. Le date vengono convertite in stringhe e richiedono una ricostruzione manuale con new Date() durante il parsing. Per strutture dati complesse, può essere necessario implementare una logica di serializzazione personalizzata.
Casi d’Uso Pratici
Le applicazioni pratiche di Web Storage sono numerose e coprono esigenze comuni dello sviluppo web moderno:
Preferenze utente: salvare la scelta della modalità chiara/scura, la lingua preferita, le dimensioni del testo o la configurazione del layout. Queste preferenze vengono memorizzate in localStorage e applicate automaticamente ad ogni visita, migliorando l’esperienza utente senza richiedere un account.
Stato dei form: salvare i dati inseriti dall’utente in un modulo lungo per proteggerli dalla perdita accidentale. Se l’utente chiude la scheda o la pagina si aggiorna involontariamente, i dati possono essere recuperati dal localStorage e reinseriti nel form. sessionStorage è più appropriato se i dati non devono sopravvivere alla chiusura della scheda.
Carrello della spesa: memorizzare i prodotti aggiunti al carrello in localStorage permette di mantenere il carrello tra le sessioni senza richiedere un account utente. Questo approccio è utilizzato da molti e-commerce per gli utenti non autenticati.
Cache di dati API: memorizzare temporaneamente le risposte delle API per ridurre le chiamate al server e migliorare le performance percepite. Si associa un timestamp ai dati per implementare una logica di scadenza e garantire che i dati non diventino obsoleti.
Limiti di Storage e Considerazioni sulla Sicurezza
I browser impongono un limite di storage per origine, tipicamente intorno ai 5MB per localStorage e 5MB per sessionStorage. Questo limite varia tra browser e può essere modificato dalle impostazioni dell’utente. Quando si supera il limite, il browser genera un’eccezione QuotaExceededError. È buona pratica wrappare le operazioni di scrittura in un blocco try-catch per gestire questa eventualità.
Dal punto di vista della sicurezza, Web Storage non deve mai essere utilizzato per memorizzare informazioni sensibili come password, token di autenticazione, dati di carte di credito o informazioni personali identificabili. I dati nello storage sono accessibili da qualsiasi script JavaScript eseguito sulla pagina, rendendoli vulnerabili ad attacchi XSS (Cross-Site Scripting). Se uno script malevolo riesce ad essere eseguito sulla pagina, può leggere e inviare tutti i dati dello storage a un server esterno.
L’evento storage viene generato quando i dati di localStorage vengono modificati da un’altra scheda o finestra della stessa origine. Questo evento permette di sincronizzare lo stato tra schede diverse, ad esempio aggiornando il carrello in tutte le schede quando un prodotto viene aggiunto in una di esse. L’evento non viene generato nella scheda che ha effettuato la modifica, solo nelle altre schede.
Per approfondire come collegare i file JavaScript che utilizzano Web Storage alle tue pagine HTML, consulta la nostra guida su come collegare CSS e JavaScript.
Hai bisogno di aiuto con l’implementazione di Web Storage nella tua applicazione web? G Tech Group offre servizi di sviluppo web professionale e consulenza tecnica. Contattaci a su*****@********up.it o via WhatsApp al 0465 84 62 45.