zurb/foundation-apps — pull request #26 by AntJanus (2014-10-03 13:57:45+00:00)
Title: [WIP] Modal directive prototype

I've been mulling this over in my head for the past few days and here's an early prototype of the Modal as a directive. Here's how it works:

1. the directive takes advantage of `transclude` which means that whatever you put in between the `

` will be compiled by the directive and show in the template (by default, it's appended to `

`).
2. whatever variables you'd like to present in the modal, you'll have to pass via the `args` attribute
3. changing the show variable from `false` to `true` will trigger the modal.
4. because of CSS transitions, the modal automatically animates

Since the variables you pass into the directive are two-way bound, whenever you change the information you passed into the `args`, the directive updates as well.

There are some caveats to this solution:

To use the modal or have several modals on hand, all the directives have to be ready on the page and cannot be dynamically created. Each directive that a controller has access to will require its own `showModal` trigger and `show` variable that the directives watch for. That's a lot of repetition.

Angular-UI got around this by creating some great architecture to show modals. This includes a `$modal` provider which creates modal instances. This means that directives are programmatically controlled. The upside to this process is that:

- modals become a module dependency (much like $scope or services). This means that the `template.html` does not get polluted with modals that may not have to be used
- modals can be created on the fly OR can be pre-created (via some configuration file and then fired off)
- modals can use `templateUrl` which means that instead of housing our modal html within a page template, we can have different modal partials separately. This is a BIG plus

It suffers from some of our previous problems such as each modal having to have its own open function (or a refactored "open(modalName)") but I don't think we can get around that. Luckily, in this case, we don't need a dedicated `modalVisible` style variable.

I think this would be much cleaner; however, the solution in this PR mirrors some of the simplicity of the core foundation modal solution. So as a side note, maybe this current solution may be better especially if we add some boilerplate to deal with the numerous `open` functions.