extending marker with labels support to markers directive

[fwitzke]

it's far from perfect but might be useful

[nmccready]

This may have to wait to after r1-dev is released. It also needs to have specs and pass with existing specs.

[nmccready]

Markers does not have a spec yet, but I should soon.

[fwitzke]

I'll take a look, but it seems the build failed while fetching npm dependencies, it passed locally, although I didn't add specs to my code I think I didn't break the existing ones :)

Also, if you have any suggestion on how to better handle labels for the markers directive I'd like to hear, I couldn't thing of anything else.

[nmccready]

Redoing the pull or going another route? Sorry I have been slammed w work.

[fwitzke]

I'll try a different approach for this, no worries man!

[nmccready]

👍

[fwitzke]

@nmccready: considering MarkerWithLabel is inherited from google.maps.Marker, which approach do you think makes more sense to handle this?

• having a child element to represent the labels:

<markers models="markers" coords="'self'">
  <markers-labels content="'title'" anchor="22 0" class="marker-labels"/>
</markers>

• or specifying the label options directly into markers:

<markers models="markers" coords="'self'" labelContent="'title'" labelAnchor="22 0" labelClass="marker-labels">
</markers>

• or even as an options object:

<div ng-inti="labelOpts= {content: 'title', anchor: '22 0', class: 'any'}">
  <markers models="markers" coords="'self'" labelOptions="labelOpts">
  </markers>
</div>

[solidspark]

Going to chime in on the case of child elements: When you have a map with many markers, you want to keep the number of DOM elements down to reduce potential GC thrashing when ng-repeat is used.

Semantically, I think the last two options work fine, but the 2nd option is probably the most angular-like of the 3.

[nmccready]

Thanks for this input as Markers was created in the first place for this specific reason.
👍

[fwitzke]

Thanks for the input, I started with the first approach and saw it didn't make much sense.

Will rework that and send another pull request soon.

[nmccready]

Referencing this issue to PR #139