Using ui-sref-active[-eq] with ng-repeat causes a race condition

[joshuahiggins]

As the title states, when using ui-sref-active or ui-sref-active-eq on a dynamically generated element, such as one created via ng-repeat, the element is not always ready for classes to be applied when $stateChangeSuccess is fired. This causes the classes to not apply on the initial state load, but they are applied on subsequent state changes.

Sample markup:

<ul>
  <li ng-repeat="nav in vm.navItems" ui-sref-active-eq="current" class="{{nav.classes}}">
    <a ui-sref="{{nav.state}}">
      <span ng-bind="nav.text"></span>
    </a>
  </li>
</ul>

Although UI Router matches the state properly, the update() fails to apply the classes as $element is not yet available on the DOM.

In the above code, removing the {{nav.classes}} resolves the issue, which leads me to believe it's simply a race condition between the DOM and UI Router. Wrapping the $element.addClass(activeClass) in a $timeout resolves the issue, though it causes numerous unit tests to fail.

[eddiemonge]

Sidenote: class="{{nav.classes}}" is kind of bad on its own. It should really be ng-class="nav.classes"

[joshuahiggins]

Good point. Still, I was just illustrating that in some conditions the the DOM is ready while in some it's not. In my own code, there are no extra directives on the ng-repeat elements but the classes still aren't applied on initial load due to the classes being applied before the digest cycle has finished.

[tiagoroldao]

I just got to this as we needed this very functionality and were running 0.2.13

While this solves part of the issue, it does not work for truly dynamic data - ui-sref elements will push to ui-sref-active[-eq], but do nothing when $destroy-ed

[christopherthielen]

Plunker: http://plnkr.co/edit/TFmqKJln3cXKkAxS5PrW?p=preview

[christopherthielen]

No longer using $timeout. Now fixed by using $evalAsync
http://plnkr.co/edit/TFmqKJln3cXKkAxS5PrW?p=preview