3 ms·
Good point I'll see if I can clear up that terminology in the post. You are also correct that you could use the background page as an alternative persistance l
by mikeknoop 15y ago
Good point I'll see if I can clear up that terminology in the post.
You are also correct that you could use the background page as an alternative persistance layer instead of LocalStorage. LocalStorage is obviously more applicable in non-extension environments. Is there a big benefit to using background pages in a Chrome Extension over LocalStorage simply for storage?
One thought for future work: load the Backbone app into the background page when the browser starts. Whenever the popup loads, simply update the Viewport view's element with Viewport.setElement() to be the root popup body element. This might allow persistance between popup loads.
- jaredsohn 15y agoThe benefit isn't that big. From the standpoint of writing quality code, I think it is better to use the background page instead of LocalStorage in that it lets you avoid writing to disk (which requires space and has worse performance than using memory, although at this scale the difference is trivial) and doesn't pollute your LocalStorage namespace as much. An advantage of the LocalStorage approach is your readers can write code in a way similar to how they would if you were not writing an extension and it makes the material more accessible in that it requires less understanding of how Chrome extensions work.
- jdavid 15y agotwo points -localStorage works on the background.html page -when content scripts access localStorage, they do so at the domain level of the url
- jaredsohn 15y agoI don't understand the purpose of your points here. * localStorage also works from the popup (using the same storage as the background; that's how the tutorial was able to work). * We're trying to get data working in the popup here, so how localStorage works in the contentscripts is irrelevant for solving this problem.