store configs to firebase + allow sharing

[stephenplusplus]

Fixes #33
Fixes #34

To Dos

• Figure out how to present error messages
• Get a review of how I'm using promises
• Get a review of architecture - did files go in the right place?
• Show if a configuration name is taken onkeyup

This implements some firebase persistence, changing the default storage driver to the new "FirebaseDriver".

There are also two services created:

• firebase - Has one method, getRef, that returns a promise that returns an authenticated ref. Auth is done with the same token we already have from the user being logged into the console with their Google account.
• configuration - Easily access a global configuration.

What's a global configuration? For a better understanding of that, let's look at the schema stored in Firebase.

- `configurations` - stores a list of plug-ins and their configuration using a unique name. - `projects` - stores a list of projects.

Let's open up configurations:

• creator - Used for firebase security rules. Anyone can create a configuration, but only the original creator can make modifications to it.
• lastModified - In case we ever find that useful.
• plugins - This is a clone of the plugin configuration that is currently persisted in localStorage. It's likely going to change as we go, so we don't need to dig into the specifics of that object here. Whatever changes we make will automatically go here.

Now, projects:

• lastModified - Again, in case we need this some day.
• plugins - Exactly as described above.

How this all comes together

Anytime a user makes changes to their settings, it is persisted to Firebase, keyed by the project they're making changes for.

There is a new "Share your configuration" button. This brings up a dialog that lets the user give it a name. After doing so, it returns a URL that will load the config, something like: http://stephenplusplus.github.io/phoenix/#/projects/import/the-name-you-chose

When another user goes to that URL, they get a prompt to select the project they want to apply those settings to. After they click "Ok", it redirects them to their project, where any settings they previously had have now been replaced.

This is a work in progress, so that last part about replacing everything won't be permanent. Instead, I think we want to go the "cards" route brought up in #29. That way, when a user hits an import URL and selects a project, it doesn't affect their old settings at all, or worry about trying to merge them. It will just create a new "card" by the same name of the configuration (e.g. "easy-storage-ui") under their project, and when they visit it, they'll be able to tweak the plug-ins to their needs without affecting anything else.

This would require some changes in Firebase and the site, so @callmehiphop, we should sync up sometime soon to decide how to proceed.

For now, HERE'S A PREVIEW: http://stephenplusplus.github.io/phoenix

[callmehiphop]

Overall, I think the db layout looks good. Couple of questions

1. What do we plan on using isEnabled for? I would think if it's not enabled it wouldn't show up in the db.
2. Do we plan on creating a third section for users that show which presets they typically use? I know we add the default to the projects section, but I'm sure they're going to want the ability to create multiple presets without sharing any?

[callmehiphop]

Have we looked at using angularfire?

[callmehiphop]

Generally I use .factory + revealing module pattern for services

[stephenplusplus]

What do we plan on using isEnabled for? I would think if it's not enabled it wouldn't show up in the db.

I figured I wouldn't get too attached to the structure of the json for now. Firebase will store any object you give it, so as we finalize that we can make changes. In particular with isEnabled, I thought you talked about getting rid of that altogether, when our Settings page turns into more of a search/configurable result page. But again, that can be discussed as we develop. We'll just remember to separate view properties from model properties, maybe coming up with a convention to help the FirebaseDriver filter them out more reliably.

Do we plan on creating a third section for users that show which presets they typically use? I know we add the default to the projects section...

What is the default for a projects section? Did I forget about something we talked about?

...but I'm sure they're going to want the ability to create multiple presets without sharing any?

That's a good idea! Maybe we can change the wording of "Share your configuration" to "Save this configuration" and then have a section of saved configurations appear:

• when you're in the projects listing of cards, there can be an empty [ + ] card, that when clicked brings up a list of configurations you can use to create a new card + apply the settings from a saved configuration
• when you're in a project, in the sidebar ("Apply a configuration" -> Dialog -> Select from a list)

I plan to elaborate on my vision of the somewhat abstract "cards" concept tomorrow (re: #29) with a quick mockup.

Have we looked at using angularfire?

Yep, I actually had it included at first, then realized I was only using the raw library. It's nice that it promisifys stuff, so I'll give it another try.

[callmehiphop]

What if instead of having a share configuration button in the left nav, we had a project configuration button instead. It would take us to a view where we could:

• configure currently enabled plugins
• switch presets (this would also refresh the currently enabled plugins list)
• import presets
• share presets

[callmehiphop]

You could wait to create the deferred object and do something like..

if (ref.getAuth()) {
  return $q.resolve(ref);
}

[callmehiphop]

@stephenplusplus per our discussions last Thursday, I've made a fairly hefty refactor to our state hierarchy. Let me know if you have questions/comments/concerns