I never knew about these helpers!!

Naught naughty

I already have a fixup commit at the end 😛

although this is very clever "two" and "too" are very similar and actually make the test harder to follow.

The cleverness credits go to the original test 😃
I can change it.

the test description here seems like a hybrid of the two tests above :-)

Is it worth adding an expectation that it should have the class "orange" here?

This description makes hard to understand what is actually being tested.

Are you saying that ngClass is not removing old classes when both the $index and the expression value changes?

It might be because I was trying to solve it differently at first. Here is what was happening before this change:

1. Assume ng-class-odd="foo", $index = 0, foo = 'foo'. The element has className === 'foo'.
2. If the $index and foo change simultaneously, say $index = 1, foo = 'bar', then:
   1. The attr[name] watch kicks in first and it checks if scope.$index & 1 === selector (i.e. it uses the current value of $index to determine if it needs to update the classes). It decides it doesn't need to do anything, so at this point the element still has className === 'foo'.
   2. The $index watch kicks in. Since it determines that $index & 1 !== old$index & 1, it decides to remove the classes. But it tries to scope.$eval(attr[name]) which now evaluates to 'bar'. So the element will still have className === 'foo'.

Basically, the problem is that both watch-actions check against the current value of each other to determine what to do, which fails when both change in the same digest.
I.e. the attr[name] watch uses scope.$index (while it should use the previous index) and the $index watch uses scope.$eval(attr[name]) (while it should use the previous value - the "old classes").

The commit fxes it by:

1. Moving the $index watch before the attr[name] watch.
2. Using oldVal from the $index watch to add/remove.

This way, when the $index & 1 changes, the $index watch will correctly add/remove the classes and then the attr[name] watch will update the classes (i.e. add the new ones) if necessary.

I hope this makes sense 😃

How about:

It should add/remove the correct classes when the expression and $index change simultaneously

ahah!

Maybe this will be better ?

function arrayDifference(tokens1, tokens2) {
      var tokens1Length = tokens1.length, tokens2Length = tokens2.length;

      if (!tokens1 || !tokens1Length) return [];
      if (!tokens2 || !tokens2Length) return tokens1;

      var values = [];

      outer:
        for (var i = 0; i < tokens1Length; i++) {
          var token = tokens1[i];
          for (var j = 0; j < tokens2Length; j++) {
            if (token === tokens2[j]) continue outer;
          }
          values.push(token);
        }

      return values;
    }

I thought about that too. The "problem" is that tokens1/tokens2 can be undefined. So, "caching" their length gets more complicated (to the point it shouldn't make any difference).

I also thought about just caching it for the for loop (e.g. for (var i = 0, ii = tokens1.length; i < ii; i++)), but I think the VM will detect that there is nothing mutating .length inside the loop and make that optimisation itself (this is just an assumption - maybe I am wrong).