interval-braining/interval-braining — pull request #3 by tdg5 (2014-02-04 14:21:00+00:00)
Title: Progress check

Hello, hello. I'm checking in with my progress so far on working to realize a modular card UI.

So far it's composed of 3-4 components, but I think this needs to be further broken down to best leverage modularity. I will get more into that later.

I'm approaching almost everything as angular directives at the moment. I went this route for a few reasons.
* They seem to be the smallest unit of reuseable UI component. Not that they're small, just more minimal than a controller#action type view.
* They have built in mechanisms for talking to parent/children directives and requiring certain directives in their ancestry.
* They follow typical angular DI strategy which means each view component need only be concerned about it's own dependencies. They don't leak into the surrounding mark up.

At the top of the stack, (for the moment, definitely need and will have layers above later), is a card. The main responsibility of a card right now is to provide the API by which the views of the card can interact with the card and each other. This API is contained mostly within cardController in card.js. Using cardController, the card directive adds the card to the scope. More or less straight forward I think.

Below the card are any number of card views. At the moment I'm more or less keeping to the front/back ideology. But something we should bear in mind is that we are not dimensionally limited in the same way that index cards are. A card could have many phases. I'm not sure how I feel about this though, because it makes correct/incorrect less binary. Something to think about though. I digress.

So you can have any number of card views. To facilitate some of the common behavior/underpinnings of card views, I create a cardViewFactory angular service. The factory basically provides a new method that expects what is otherwise an ordinary directive definition. The passed in attributes are merged with common card attributes, returning a new directive object that plays nicely. By "plays nicely" I mean two things. First, all card view directives insist that somewhere above them a card directive exist. Second, when a card view is compiled and linked in to the UI, it registers itself with that ancestor card. After this any provided link function is called. Registering with the ancestor card allows the ancestor card to know which views exist and facilitate switching between them.

That's more or less the programmatic side of what is here. The two card view instances included here are very simple and primarily just identify the template they use.

If you spin up a server, you should see a basic card with functioning flip, back, correct, and incorrect clickables.

As I mentioned before, I think additional break up is needed at the card view level. This additional break up would facilitate reusing directives that render the card or accept input from the card view. I haven't thought all that deeply about how that break up will go yet, but I imagine it's the next thing I'll look at.

How does this seem to you so far? I imagine some of the angular directive stuff will be confusing, but it's not as bad as it seems once you dig in a little. This has been the most valuable resource I've come across: http://docs.angularjs.org/guide/directive

Let me know what you think or if there are any concerns or problems you have with what I have here so far.