You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Current behavior
Say you have [ngClass]="{'fa fa-thumbs-up': true, 'fa fa-thumbs-down': false}" specified.
Looking at your code, you apply classes where the value is true, then remove classes where the value is false. This means "fa" never appears as a class. I think this leads to surprising behavior. Classes traveling in pairs like this are really common.
Expected behavior
I think it makes more sense to first remove any classes associated with false, then re-add any associated with true, rather than the other way around. The logic is giving removal precedence, even though I see classes with false as should not be applied.
I mean, perhaps, there are people who use this directive the other way around, putting default classes in a "class" attribute and then removing them using this directive, but I would guess they are a rare group. It makes way more sense to add classes via ngClass than to remove them.
Minimal reproduction of the problem with instructions
Check out the ngClass example above.
What is the motivation / use case for changing the behavior?
This isn't the expected behavior and these types of class pairs are common.
Please tell us about your environment:
Windows, webpack
Angular version: 2.0.X
Just ran this against 4.1.3.
Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
all
"Why not just move the 'fa' out?", you might ask. Something like this: <span class="fa" [ngClass]="{'fa-thumbs-up': isPositive, 'fa-thumbs-down': !isPositive}"></span>. That would certainly solve the problem for some people.
That makes sense when using the same condition, like isPositive in the example. But, consider this use case:
You have a form and you want to use classes to indicate when the form is valid or invalid. However, prior to submitting the form, you don't want to apply any classes. You wouldn't want users to get blasted with validation errors the second they open the page. To support that, you create two boolean properties: isValid and isInvalid.
You use bootstrap4 to apply classes to a card, either card-inverse card-success or card-inverse card-danger. The card-inverse class actually turns the text white, making it impossible to see unless one of the other two classes are set. When you try the code below, you run into the issue I am describing:
When valid, card-inverse is added then removed, and the text remains black on top of a green background, making it hard to see. If you try to move the card-inverse out into a class attribute, the text is always white, even on a white background.
The workaround is to call a function; something like this:
That works for now but that's a lot of overhead, also forcing class names into the typescript backend rather than in the HTML where I'd prefer it live.
@tytskyi I definitely prefer that. It is a good way to keep the classes in the HTML, too.
When I submitted this, I figured there are too many people using ngClass to change its behavior at this point. I figured I'd put this out there so others might come across it and benefit from alternative approaches like the one you just posted. Thanks!
Activity
jehugaleahsa commentedon May 29, 2017
"Why not just move the 'fa' out?", you might ask. Something like this:
<span class="fa" [ngClass]="{'fa-thumbs-up': isPositive, 'fa-thumbs-down': !isPositive}"></span>. That would certainly solve the problem for some people.That makes sense when using the same condition, like
isPositivein the example. But, consider this use case:You have a form and you want to use classes to indicate when the form is valid or invalid. However, prior to submitting the form, you don't want to apply any classes. You wouldn't want users to get blasted with validation errors the second they open the page. To support that, you create two
booleanproperties:isValidandisInvalid.You use bootstrap4 to apply classes to a card, either
card-inverse card-successorcard-inverse card-danger. Thecard-inverseclass actually turns the text white, making it impossible to see unless one of the other two classes are set. When you try the code below, you run into the issue I am describing:When valid,
card-inverseis added then removed, and the text remains black on top of a green background, making it hard to see. If you try to move thecard-inverseout into aclassattribute, the text is always white, even on a white background.The workaround is to call a function; something like this:
That works for now but that's a lot of overhead, also forcing class names into the typescript backend rather than in the HTML where I'd prefer it live.
tytskyi commentedon May 29, 2017
Don't you find that this
already reads hard?
IMO this reads more obvious:
I think the only good use case for
[ngClass]- is when you don't know classnames in advance and you want to generate them in runtime.jehugaleahsa commentedon May 29, 2017
@tytskyi I definitely prefer that. It is a good way to keep the classes in the HTML, too.
When I submitted this, I figured there are too many people using
ngClassto change its behavior at this point. I figured I'd put this out there so others might come across it and benefit from alternative approaches like the one you just posted. Thanks!ericmartinezr commentedon May 29, 2017
Relevant #5763 (comment)
vicb commentedon May 30, 2017
<div class="card-inverse" [ngClass]="{'card-success': isValid, 'card-danger': isInvalid}"></div>should also work
angular-automatic-lock-bot commentedon Sep 11, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.