[3.1.0] "class" attribute not being recomputed

[boris-petrov]

We have something like this in a template:

{{some-component classNames="some-class fade" class=(if isLoggedIn "in")}}

This used to work fine until 3.1.0 - that is, when isLoggedIn is true, in addition to the classes in classNames, in is added. When isLoggedIn is false, then only the classes from classNames are used. However, in 3.1.0 this doesn't work any more. in is not added even when isLoggedIn is true. It works only if we add a non-empty string to the else clause - (if isLoggedIn "in" "some-non-relevant-class").

[jamesarosen]

I first ran into this with a ternary if:

{{my-button
  class=(if isSubmitting 'button--in-progress' (if isSubmitted 'button--complete'))
}}

where component:my-button also has classNameBindings.

I converted it to a computed property and found it has the same problem

submitClass: computed('isSubmitted', 'isSubmitting', function() {
  if (this.get('isSubmitting')) return 'button--in-progress'
  if (this.get('isSubmitted')) return 'button--complete'
  return 'cruft' // with this line, it works; without it, it fails
}),

[mydea]

I also ran into this, and this basically prevents us from using Ember 3.1, as it breaks our app in quite a lot of places (and was rather hard to track down!). Would be awesome to get a fix for this :)

[rwjblue]

Does someone have time to put together a repo demonstrating the issue or possibly a failing test case PR here?

[mydea]

Sure! It's pretty easy to reproduce.
See: https://github.com/mydea/ember-issue-reproductions/tree/ember-3-1-class-recomputation

The relevant code is here:
https://github.com/mydea/ember-issue-reproductions/blob/ember-3-1-class-recomputation/app/templates/application.hbs

Also note, interestingly, if hasClass is true by default, the toggling does work for both fields.

[rwjblue]

Just to confirm here, this is only an issue with passing class as an argument to a component invocation, right? (E.g. <div class={{if hasClass ‘true’}}></div> is not an issue)

[rwjblue]

I think this is likely similar to #16379 (which is fixed by #16563). Basically somewhere in the pipeline (likely curly component manager) we are doing a truthy check where we shouldn't be...