tosdr/tosdr-firefox — pull request #23 by clarkbw (2014-10-11 23:23:23+00:00)
Title: bit of a rework

Hey -

I've been cleaning things up a bit with a different code layout and style. I'll try to describe it all here so it makes sense. I haven't finished with all your tests but I wanted to get this on the radar so I'm not trying to keep up with the changes in master at the same time.

main.js: to make things more test friendly you really want your main file to be just the glue so I've removed most of the functionality in there and pushed it into modules.

ratings.js: utility functions for ratings text and icons to be shared across modules

tos-notifications.js: moving this out into its own module allows the notification system to (eventually) have tests of its own. All it needs to do is watch the current URL from the tabs module and respond appropriately.

tos-panel.js: wrap module around the panel so it can act more independently just responding to clicks and fetching data as needed. By exporting the panel itself it can be used in the button module.

tos-urlbutton.js: similar to the notifications this module watches for URL changes and updates the button appropriately, opening the tos-panel when clicked.

For all fetches and related storage I moved things into a service directory `lib/service/`

service/database: runs the "cache" for your API by saving things to the simple storage database and requesting updated versions as needed. I chose a completely promise based API for this module because it allows us to fetch as needed by chaining Request calls and possibly move to an indexedDB version in the future without much issue.

service/match: this is the "does this url match our db" module just so we can share it in multiple modules as needed.

service/point: Runs remotes Requests. With the previous API I needed to go fetch points separately, it's nice that has changed but I reused this code to fetch at against the new v1 api for now. This should probably be cleaned up.

service/service: Runs remotes Requests. Not the best naming choice, this is for fetching services individually and updating the master list as needed.

service/setup: Intended to be run from the main module. This simply initializes the databases and ensures they will auto-update every day.

utils/service: holds the URLs for the services. Multiple modules require this info so I used this module to share that. To make testing easier I set a pref for the base domain.

utils/tld: a simple module to get the top level domain for a given URL to make matching things easier.

utils/log: I'm not sure this is necessary, you seemed to want to have more control with logging so I moved things over here but I'm not clear what your intentions were.

Hope this is helpful, drop questions or comments in here.