When I mix class + expression with ng-class, the ng-class is not being compiled if expression is broken or fails to return anything

[iladarsda]

I noticed when I mix ng-class with class + expression (class="something-{{data}}"), if the expression fails to return anything (does not exist for example), than the ng-class will not get compiled at all.

Also, it only happens when the broken expression is in the middle of the class <div class="stuff-{{ok}} another-{{nothing}} third-{{ok}}"></div>.

Here is fiddle example: http://jsfiddle.net/seefeld/4z4s4hhs/6/

[gkalpak]

I fact it doesn't happen when you say it does.
It happens when there are two or more interpolations (even on the same class).

Here is the updated fiddle: http://jsfiddle.net/ExpertSystem/4z4s4hhs/15/

BTW, this seems to have been broken in v1.3.0-beta.19.
It works as expected in v1.2.25 and all 1.3.0 betas up to v1.3.0-beta.18.

[gkalpak]

Let's assume the following html:

<div class="color-{{color}} size-{{size}}" ng-class="(size>10)?'font-large':'font-small'">
    ...
</div>

evaluated against the following context: {color: 'red', size: 20}

---

The complexity of this is kind of beyond my reach, but I'll just post my observations from trying to track the problem down (in hope of saving someone some time):

(A)
There is a difference in the sequence of events between 1.3.0-beta.19 (which introduced the issue) and 1.3.0-beta.18.

• In beta.18:
  1. The callback of the watcher of attribute-interpolation gets executed, which sets the element's className to color-red size-20.
  2. The callback of the watcher of ngClass gets executed which sets the element's className to color-red size-20 font-large.

This is the expected outcome.

• In beta.19:
  1. The callback of the watcher of ngClass gets executed first, which sets the element's (still uninterpolated) className to color-{{color}} size-{{size}} font-large.
  2. The callback of the watcher of attribute-interpolation gets executed, which sets the element's className to color-red size-20. (Notice how the font-large class was removed.)

This happens (or so I say), because attribute-interpolation interpolates the string color-{{color}} size-{{size}}, then ngClass changes the className, then interpolation determines that the original string should color-red size-20 and (without being aware that the class "attribute" has been changed) it sets its value to the result of the intrpolation of the original string.

(B)
I believe (without being able to prove it) that the above behaviour is caused by introducing asynchronous evaluation (by means of $evalAsync()) inside the $watchGroup() method:

$watchGroup: function (watchExpressions, listener) {
    ...
    forEach(watchExpressions, function (expr, i) {
        var unwatchFn = self.$watch(expr, function watchGroupSubAction(value, oldValue) {
            ...
            self.$evalAsync(watchGroupAction);

(CCing @IgorMinar because he seems to be the one introducng $evalAsync())

(C)
If we only have one interpolation in the className (e.g. class="color-{{color}}"), then the above example works as expected. Why ? I will tell you why :)
Because $watchGroup() treats a watchExpressions array with just one element differently:

$watchGroup: function (watchExpressions, listener) {
    ...
    if (watchExpressions.length === 1) {
        return this.$watch(watchExpressions[0], function watchGroupAction(value, oldValue, scope) {
            ...
            listener(...);   // <----- See ? No `$evalAsync()` here.

(D)
Again I can't prove it (yet), but I have a very strong feeling that this problem affects all attributes (not just class).
Basically, I believe that this problem is likely to arise any time there is an attribute whose value is an interpolated string and someone (a directive) also changes the value of that attribute (not replacing it, but modifying it).

Generally, I think attribute interpolation should check (how?) that there has been no modification to the original template string (based on which the new value has been computed). If the original template string has been modified, then the computed value is useless and interpolation should rerun.

I am not sure this is indeed the problem, I am just speculating here.
But if it is, I could imagine a solution to be something along these lines:

1. Inside the watch callback add a check: a comparison between the original template string (a reference to it needs to be kept) and the current template string*.
2. If they are the same, proceed as usual.
3. If they are different, throw the computed value away and start all over again.

*: In order for this to be feasible, there needs to be a way to extract the template string from the current interpolated string. I.e.:

1. Initially: Template string: color-{{color}}, String value: color-{{color}}
2. Resolve {{color}} to red: Template string: color-{{color}}, String value: color-red
3. Someone modifies the string: String value: color-red hello-world
   Somehow, we need to be able to infer the new template string from this: color-{{color}} hello-world
4. Things can get ugly if someone modifies part of the string that belongs to the original template.

Oooor...maybe I am overthinking this. The solution might be totally different.

---

Anyway, sorry for the large comment and let me know if I can provide any further help :)

[iladarsda]

I am impressed. Thanks for the in-depth explanation. I am working around the issue by making sure I only bind expressions that I am sure will return, or avoiding mixing class with ng-class all-together.

[gkalpak]

@seefeld:
Jut making sure I am clear: The problem has absolutely no connection to whether the expression will return something or not (as demonstrated in my fiddle - see second example).

The problem arises only when ngClass is used together with a className that contains 2 or more interpolations, basically 2 or more pairs of {{...}} (be it on the same class or on different ones).

So, avoiding mixing ngClass with interpolated classNames should work around the problem (until this is fixed).

[caitp]

@gkalpak's interpretation of the issue looks right --- I'm not sure why we're deferring invokation of the listener (this seems a bit weird).

I'd like to get this fixed properly, but I don't want to write a patch until I know specifically what we're doing this for

[tedbeer]

Escalate!
ng-hide and ng-show are also affected - http://jsfiddle.net/tedbeer/4z4s4hhs/16/