Backbone.js and Chrome Extensions
zapier.com
zapier.com
The extension would still need to recompute it once every time it is starts up, but since it is computable I don't think it belongs in LocalStorage. (You wouldn't store something like this in the registry if you were writing a Windows program; you'd just keep it in memory.)
Also, the article could use a bit of improvement in terminology. When it talks about 'loading the extension', it really means displaying the popup. I think of loading the extension as in starting up the background page via the extensions window.
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.
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.
-localStorage works on the background.html page
-when content scripts access localStorage, they do so at the domain level of the url
* 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.
I'm curious, did you do anything special to work around fresh API hits each time the popup is loaded (ie. LocalStorage)?
Have you ever looked at something like this?
When you define a browser_action inside your manifest.json file:
"browser_action": {
"default_icon": "icon_16.png",
"popup": "popup.html"
},
Now, our foray into Chrome Extensions pretty much ends there. We load all our Backbone code via popup.html and let it do its thing. We did not look at any other of the mechanisms Chrome provides to extensions such as contentscripts.
With that said, I also see a lot of value in leveraging Backbone's Model and Bindings within contentscripts and it would be something worth exploring -- but it wasn't directly applicable to understanding how Backbone could work for us in overhauling our frontend.
Thanks for your post!
Popups, on the other hand, get their scripts loaded into a brand new document when the icon is clicked and rendered into the popup bubble.
Backbone makes model/collection caching very easy so my preferred method would be to override Backbone.sync to store data inside LocalStorage.
There are a few blog posts out there with tricks on how to persist state between popup loads (unloading the popup DOM into the background page...). I think these strategies would break a Backbone app due to how view bindings work. I'd be curious to know any other ideas on how to persist the actual state (and not just model/collection data) between popup loads.
EDIT: To answer my own question a little bit, you could probably get fancy with http://code.google.com/chrome/extensions/background_pages.ht... but I'd need to do more research on the relation between background pages and popups.
I've tabled it for now. I'm 99% sure the way to go is to put a popout link on the popup, setPopup to null and then bind the click listener for the popup icon to focus the popup. If the user closes the popped out popup reset setPopup and the process starts anew. I'll still be overring backbone sync and keeping all the data in the background.
Loaded question - I'm a co-founder of Trigger.io :-D
Eventually, I think we will have "frontend" views across many devices and machines (alluded to in the article, it's just to easy to create another view). We haven't tested the performance on any mobile clients yet but I would definitely look into a solution like Trigger.io when we get to it.