-
Notifications
You must be signed in to change notification settings - Fork 25.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(common): deprecate ngStyle
and ngClass
#58860
base: main
Are you sure you want to change the base?
Conversation
72b621a
to
772bff5
Compare
ngStyle
and ngClass
ngStyle
and ngClass
ddf04fc
to
2150246
Compare
The overhead of those directives doesn't outweighs the few additions cases it supports compared to compiler provided `class` and `style` bindings. DEPRECATED: Both `ngStyle` and `ngClass` directives are deprecated, use the respective direct bindings instead.
2150246
to
6760490
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Reviewed-for: public-api
Reviewed-for: fw-core
This is a deprecation of a very widely used feature. If it is to be deprecated, I'd like to see clear examples in the deprecation comments showing how to migrate code where key-value expression was used |
@DmitryEfimenko key-value expressions are already supported by the existing bindings. The numbers are quite important in Google's monorepo, ( Also a migration will be provided to migrate the cases where is it possible to migrate the templates but it will not be possible to migrate everything as there are some breaking cases that will require manuel updates. Alonge side the migration, we'll have a dedicate doc. That being said, this will probably be a soft deprecation. |
What about unit suffixes in style? I found this link in this PR: #40623 Is it actual or not? |
This behavior works only for the directive but that can easily be worked arround without having to pull the whole directive. |
This second use case is probably the most common, when using Angular together with styling systems that are heavily based on utility css classes, like tailwind or bootstrap (to some extent). I am a bit worried about the additional bloat that will be necessary to split all used classes and repeat the condition. Something not really uncommon like <div [ngClass]="{ 'ring ring-pink-500 ring-offset-2 dark:ring-green-500' : condition }">... Would need to become <div [class]="{ 'ring' : condition, 'ring-pink-500' : condition, 'ring-offset-2' : condition, 'dark:ring-green-500' : condition }">... Which is really not that great to look at and quite cumbersome to write. Considering alternatives, you could of course introduce a helper class in the styling of the component and use @apply like this .my-ring {
@apply ring ring-pink-500 ring-offset-2 dark:ring-green-500;
} And use the helper class like this <div [class]="{ 'my-ring' : condition }">... But this would contradict principles of tailwind to have utility and locality first (https://tailwindcss.com/docs/utility-first) and avoid abstractions (https://tailwindcss.com/docs/reusing-styles). So I am concerned and have a few questions: Is there another beautiful way of still keeping the awesome experience working with tailwind and Angular I haven't thought about? Is it possible to enhance Angular to still support keys with multiple styles/classes separated with spaces? |
|
That looks like a workaround, but not really like a legitimate replacement in my opinion. For one, having an obligatory dangling empty ternary path doesn't look really fancy 😅 For another reason, it's not really as powerful as controlling Considering the following example: <div [ngClass]="{
'ring ring-offset-2': isHighlighted(),
'text-green-500 italic': isPremium(),
'text-grey-50': !isPremium(),
}">... where My point - as abstract as it might sound - the way of setting multiple classes in object fashion by ngClass is an important feature that needs adequate replacement before discussing deprecating it. |
@dhhyi When one of the conditions becomes false, the directive will remove the classes, enlisted for this condition, even if other conditions have these classes too. The result is unintuitive and not so predictable (depending on the positions of the rules). That's why I think it should not be migrated to |
@e-oz But it's caused by undisciplined programmers, and taming them is a task for eslint. |
The overhead of those directives (additional bundle size, distinct import) doesn't outweighs the few additional cases it supports compared to compiler provided
class
andstyle
bindings.DEPRECATE: Both
ngStyle
andngClass
directives are deprecated, use the their direct bindings instead.Also, documentation the migration for this will address #40623.
Note:
The native bindings support almost the same usecases at the exception of 2 :
Set
style
(egmyStyles = { 'width.px': 100}
) wouldn't be supported either.The recommendation is to drop those space-separated-keys into separate ones and replace Sets with arrays.