window.localStorage vs chrome.storage.local

Sto sviluppando un’estensione di Chrome e ho bisogno di archiviare alcuni dati per poi ottenerli in qualche punto. Ho fatto delle ricerche sugli storage disponibili e mi sono imbattuto in quelli seguenti: window.localStorage e chrome.storage.local .

Quindi la mia domanda è: qual è la scelta giusta da utilizzare nelle estensioni di Chrome:
window.localStorage o chrome.storage.local ?

PS Sto utilizzando l’ browser action per caricare un HTML locale in IFRAME . Quindi non sto usando popup.js .

Dipende interamente da cosa farà l’estensione di Chrome. window.localStorage è una memoria HTML5. A meno che non lo si esegua nella pagina di sfondo, può solo consentire di ottenere e impostare i dati in memoria per un dominio specifico. Questo vale anche per il codice iniettato nel DOM, poiché userebbe localStorage nella pagina web.

In altre parole, non sarà ansible condividere dati su pagine Web diverse a meno che non si usi localStorage nella pagina di sfondo, che opera indipendentemente dalle pagine Web, poiché ha un URI chrome: // come dominio.

chrome.storage.local, d’altra parte, è progettato per Chrome Extensions e Chrome Apps per archiviare i dati in una posizione più centrale. Dal momento che questo non è accessibile alle normali pagine Web, ciascuna estensione ha il proprio spazio di archiviazione. Una possibilità è che la pagina di sfondo gestisca l’impostazione e l’acquisizione dei dati, mentre gli script dei contenuti gestiscono la modifica e l’interazione con la pagina web.

Tuttavia, queste API funzionano anche negli script di contenuto, e entrambe le estensioni che ho scritto usano chrome.storage.local chiamato dagli script di contenuto.

Ad esempio, ho creato una Stack App che conserva gli elementi della posta in arrivo in Stack Exchange finché non li hai effettivamente letti, chiamati StackInbox . Dal momento che i siti di Stack Exchange si estendono su centinaia di domini, ho scelto chrome.storage.local perché posso salvare l’account dell’utente e riutilizzarlo in tutti i siti, assicurandomi che i dati della posta in arrivo siano sincronizzati, ma anche direttamente nello script di contenuto.

Come semplice test, inserisci alcuni dati in localStorage su un dominio, in uno script di contenuto, e prova a estrarlo da un altro, e vedrai che i dati non saranno lì. Con chrome.storage.local, questo non è un problema.

Infine, le estensioni di Chrome e le app di Chrome sono autorizzate, poiché l’utente ha scelto di installarlo, quindi in genere possono fare più cose rispetto a un normale sito web. Ad esempio, specificando l’authorization “unlimitedStorage” nel manifest, è ansible archiviare i dati ben oltre il limite di 5 MB posto su localhosttor HTML5.

Per ulteriori informazioni, consulta la documentazione di Google su Chrome Storage .

localStorage

Professionisti:

  • var value = localStorage[key] e quindi più semplice da utilizzare: var value = localStorage[key]
  • Ha il supporto in Dev Tools: Resources> Local Storage per visualizzare e modificare.

Contro:

  • Memorizza solo stringhe, pertanto è necessario serializzare i dati autonomamente, ovvero con JSON.stringify
  • Non è accessibile dagli script di contenuto (o meglio, gli script di contesto lo condividono con la pagina e non con l’estensione), quindi è necessario affidarsi a Messaging per passare i valori ad essi.
  • Sincrono E condiviso tra le pagine di estensione in esecuzione simultanea, portando a possibili problemi di sincronizzazione.

chrome.storage.local

Professionisti:

  • Serializza automagicamente i dati compatibili con JSON, può memorizzare stringhe senza stringhe aggiuntive.
  • Completamente disponibile all’interno degli script di contenuto.
  • Supporta eventi che notificano le modifiche: chrome.storage.onChanged
  • Con "unlimitedStorage" authorization "unlimitedStorage" , può contenere quantità arbitrariamente grandi di dati.
  • Ha un bel meccanismo integrato per i valori di default:

     chrome.storage.local.get({key: defaultValue}, function(value){/*...*/}); 
  • Completamente supportato in Firefox WebExtensions ed Edge Extensions.

Contro:

  • Asincrono, quindi un po ‘più difficile da lavorare con:

     chrome.storage.local.get("key", function(value){/* Continue here */}); 
  • Non visualizzato in Dev Tools; è necessario chiamare chrome.storage.local.get(null) per ottenere tutti i valori o utilizzare qualcosa come Storage Area Explorer .

chrome.storage.sync

Come sopra, ma:

Professionisti:

  • Sincronizzato automaticamente tra le istanze Chrome registrate, se la sincronizzazione delle estensioni è abilitata.

Contro:

  • Quote inflessibili sulla dimensione dei dati e frequenza di aggiornamento.
  • A partire dal 2016-11-06, non ancora supportato in Firefox WebExtensions o Edge Extensions, quindi non portabile.

    Nota: storage.sync ora è compatibile con FF WebExtension , sebbene non sia ansible rendere Chrome e FF sincronizzati in modo nativo l’uno con l’altro.