8000 Add support for square, and curly brackets in ngClass · Issue #39835 · angular/angular · GitHub
[go: up one dir, main page]
Skip to content

Add support for square, and curly brackets in ngClass #39835

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.

Sign up for GitHub

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

Jump to bottom
Closed
JoshuaAlzate opened this issue Nov 25, 2020 · 11 comments
Closed

Add support for square, and curly brackets in ngClass #39835

JoshuaAlzate opened this issue Nov 25, 2020 · 11 comments
Labels
area: common Issues related to APIs in the @angular/common package feature: insufficient votes Label to add when the not a sufficient number of votes or comments from unique authors feature: votes required Feature request which is currently still in the voting phase feature Issue that requests a new feature P5 The team acknowledges the request but does not plan to address it, it remains open for discussion
Milestone
Backlog

Comments

@JoshuaAlzate
Copy link
JoshuaAlzate commented Nov 25, 2020 •
edited
Loading

🚀 feature request

Relevant Package

This feature request is for @angular/common

Description

Currently, we do have a lot of syntaxes supported on ngClass. But there's no way to mix up the [], and {} syntax. There are scenarios that we will need a ternary operator to choose between two sets of classes dynamically, and there's also chances that we just need one.

Describe the solution you'd like

I setup a sample where I describe the solution I like.

As you can see in there, I am comparing the key name of the object by putting it in square brackets. And when the condition false to any of the class stated, it will be return as a property key name.

<hello name="{{ name }}" [ngClass]="{
  [myCheckBox ? italic: underline]: true, 
  red: myCheckBox2, 
  serif: true}">
</hello>

<input type="checkbox" [(ngModel)]="myCheckBox" /> Style
<input type="checkbox" [(ngModel)]="myCheckBox2" /> Colour

This is what I have in mind, but it would be cleaner if we can handle it without explicitly putting true on it.

Describe alternatives you've considered

Currently, the workaround for this is to put it on a square bracket array syntax and pass an empty class in case the condition falls to the other condition.

<hello name="{{ name }}" [ngClass]="[myCheckBox ? 'italic': 'underline', myCheckBox2 ? 'red' : '', 'serif' ]">
</hello>
@Dlacreme
Copy link

This seem extremely confusing for no reason and not that easy to implement. Why don't you simply use a function which returns the correct list of classes?
In my opinion, HTML should not hold so much logic

@petebacondarwin petebacondarwin added area: common Issues related to APIs in the @angular/common package feature Issue that requests a new feature labels Nov 25, 2020
@ngbot ngbot bot modified the milestone: Backlog Nov 25, 2020
@petebacondarwin
Copy link
Contributor

I agree with @Dlacreme here. The NgClass directive syntax is already complex (and confusing) enough - ngClass is one of the most searched for terms related to Angular!

The broader feature request, here, is to support computed property names in Angular template expressions. Since, as @Dlacreme, points out the idea is to avoid too much logic in templates, I don't think that this is something that we are likely to implement in Angular core.

@petebacondarwin petebacondarwin added the P5 The team acknowledges the request but does not plan to address it, it remains open for discussion label Nov 25, 2020
@JoshuaAlzate
Copy link
Author
JoshuaAlzate commented Nov 25, 2020 •
edited
Loading

This seem extremely confusing for no reason

On which part? So I could clarify it more.

not that easy to implement

I would love to work with this once we consider to support this proposed solution.

Why don't you simply use a function which returns the correct list of classes?

That's one of the solutions that we can do apart from the example workaround solution that I have provided which is great for complex and complicated operation.

In my opinion, HTML should not hold so much logic

Well, I agree to you as well on this one. But there are also not so complicated scenarios that can be easily done with ngClass with a purpose of dynamically set CSS classes on an HTML element by databinding an expression that represents all classes to be added.

The NgClass directive syntax is already complex (and confusing) enough

I believe it is because we handle multiple syntaxes, but once you get the idea of it, it isn't that confusing.

points out the idea is to avoid too much logic in templates

Yes, I agree with you on this that it is a bad practice to bloat a lot of logical operation on the HTML; however, like on the example that I have provided, it is just a simple operation. And since you have mention that ngClass is complex, one thing that we can do to make it simple by putting this kind of syntax that will make it cleaner and increase readability.

@ulrikwalter
Copy link

I think, it's better way:

<hello name="{{ name }}" [ngClass]="{ italic: myCheckBox, underline: !myCheckBox, red: myCheckBox2, serif: true}"> </hello>

@angular-robot angular-robot bot added the feature: votes required Feature request which is currently still in the voting phase label Jun 4, 2021
@angular-robot
Copy link
Contributor
angular-robot bot commented Jun 4, 2021

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

@shivamd20
Copy link

This seem extremely confusing for no reason and not that easy to implement. Why don't you simply use a function which returns the correct list of classes?
In my opinion, HTML should not hold so much logic

I prefer to keep all knowledge about styling in the HTML file itself. It plays nicely with tools like PurgeCSS.

@angular-robot
Copy link
Contributor
angular-robot bot commented Jun 25, 2021

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

@angular-robot angular-robot bot added the feature: insufficient votes Label to add when the not a sufficient number of votes or comments from unique authors label Jun 25, 2021
@JoshuaAlzate
Copy link
Author

Don't we consider this feature request? I still think it would be really helpful. I'm thinking to create a POC for this one.

@jessicajaniuk
Copy link
Contributor

@JoshuaAlzate It unfortunately didn't get the required amount of votes to be considered. Our feature request process requires at least 20 community upvotes before we add it to be considered.

@JoostK
Copy link
Member
JoostK commented Mar 15, 2022

Support for the computed property name syntax is tracked in #43485.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area: common Issues related to APIs in the @angular/common package feature: insufficient votes Label to add when the not a sufficient number of votes or comments from unique authors feature: votes required Feature request which is currently still in the voting phase feature Issue that requests a new feature P5 The team acknowledges the request but does not plan to address it, it remains open for discussion
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
7 participants
@petebacondarwin @JoostK @ulrikwalter @Dlacreme @shivamd20 @JoshuaAlzate @jessicajaniuk
0