window.localStorage vs chrome.storage.local

问题:

I'm developing a Chrome extension and I need to store some data and then get it in some point. I did investigation on available storages and came across to the following ones: window.localStorage and chrome.storage.local.

So my question is, which one is the right choice to use in Chrome extensions:
window.localStorage or chrome.storage.local?

P.S. I'm using browser action to load a local HTML in IFRAME. So I'm not using popup.js.

回答1:

It depends entirely on what your Chrome Extension will be doing. window.localStorage is HTML5 storage. Unless you're running it in the background page, it can only allow you to get and set data into storage for a specific domain. This is also true for code injected into the DOM, since it would use the localStorage on the web page.

In other words, you won't be able to share data across different web pages unless you use localStorage in the background page, which operates independently of web pages, since it has a chrome:// URI as its domain.

chrome.storage.local, on the other hand, is designed for Chrome Extensions and Chrome Apps to store data in a more central location. Since this isn't accessible to normal web pages, each Extension gets its own storage. One possibility is for your background page to handle dealing with the setting and getting of the data, while your content scripts deal with modifying and interacting with the web page.

However, these API's work in content scripts as well, and both of the extensions I've written use chrome.storage.local called from the content scripts.

As an example, I built a Stack App that preserves inbox items in Stack Exchange until you've actually read them, called StackInbox. Since Stack Exchange sites span across hundreds of domains, I chose chrome.storage.local because I could save the user's accountId and reuse it across all the sites, ensuring that the inbox data is synchronized, while also using this directly in the content script.

As a simple test, put some data in localStorage on one domain, in a content script, and try to pull it from another, and you'll see that the data won't be there. With chrome.storage.local, this isn't a problem.

Lastly, Chrome Extensions and Chrome Apps are whitelisted, since the user chose to install it, so they typically can do more things than a normal website. For instance, by specifying the "unlimitedStorage" permission in your manifest, you can store data well beyond the 5MB limit placed upon HTML5 localStorage.

For more information, see Google's documentation on Chrome Storage.

回答2:

localStorage

Pros:

• Synchronous, and thus easier to work with: var value = localStorage[key]
• Has support in Dev Tools: Resources > Local Storage to view and modify.

Cons:

• Only stores strings, therefore you need to serialize data yourself, i.e. with JSON.stringify
• Is not accessible from content scripts (or rather, context scripts share it with the page and not the extension), so you need to rely on Messaging to pass values to them.
• Synchronous AND shared between concurrently-executing extension pages, leading to possible synchronization issues.

chrome.storage.local

Pros:

• Automagically serializes JSON-compatible data, can store non-strings with no additional boilerplate.
• Fully available within Content Scripts.
• Supports events that notify about changes: chrome.storage.onChanged
• With "unlimitedStorage" permission, can hold arbitrarily large amounts of data.

• Has a nice built-in mechanism for default values:

  chrome.storage.local.get({key: defaultValue}, function(value){/*...*/});
  

• Fully supported in Firefox WebExtensions and Edge Extensions.

Cons:

• Asynchronous, therefore a bit harder to work with:

  chrome.storage.local.get("key", function(value){/* Continue here */});
  

• Not visualized in Dev Tools; one needs to call chrome.storage.local.get(null) to get all values or use something like Storage Area Explorer.

chrome.storage.sync

Same as above, but:

Pros:

• Automatically synced between signed-in Chrome instances, if extensions sync is enabled.

Cons:

• Inflexible quotas on data size and update frequency.

• As of 2016-11-06, not yet supported in either Firefox WebExtensions or Edge Extensions, so non-portable.

  Note: storage.sync is now FF WebExtension compatible, though there is no way to make Chrome and FF natively sync between each other.