This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Rule proposal: template/attributes-order #127
Comments
Hey @SchnWalter, although I understand your concern about this specific order, I could imagine that some people would find another one better to them. Having this in mind, I believe that we could follow the proposal that we already have in Codelyzer, which gives the ability to configure the order to your liking. What do you think? |
Hi @SchnWalter , do you have any updates? |
Hey guys, I have just had an attempt to implement this rule, see this commit To implement this rule I want to be able to identify following entities to sort them further:
Done:
Not done, but can be done:
Not done and seems not possible to be done
Example:
At the parsing moment the compiler doesn't know what exactly
And all of them are valid and possible cases, which can be known only after compilation. I see these possible solutions:
@JamesHenry @rafaelss95 any thoughts/advice on this? |
Hey @nickbullock, thanks for taking a look on this! I saw what you did and I would like to share some opinions.
I guess the configuration depends as much on the level of granularity we may want with this rule. I see that you created an option for each global attribute... but if we follow up this line of thinking, we would end up with a big list of configuration (see the full list of global attributes). I think we should instead have an option for global attributes (following the link above), however I don't see the reason in separating global attributes from inputs (when not used with property binding of course, e.g. I was thinking in something more like this: {
"rules": {
"@angular-eslint/template/attributes-order": [
"error", {
"alphabetical": false,
"order": [
"STRUCTURAL_DIRECTIVE" // e.g. `*ngIf="true"`, `*ngFor="let item of items"`
"TEMPLATE_REFERENCE_VARIABLE", // e.g. `<input #inputRef>`
"ATTRIBUTE_BINDING", // e.g. `<input required>`, `id="3"`
"INPUT_BINDING", // e.g. `[id]="3"`, `[attr.colspan]="colspan"`, [style.width.%]="100", [@triggerName]="expression", `bind-id="handleChange()"`
"OUTPUT_BINDING", // e.g. `(idChange)="handleChange()"`, `on-id="handleChange()"`
"TWO_WAY_BINDING", // e.g. `[(id)]="id"`, `bindon-id="id"
]
}
]
}
}
I don't think we need to do this. We can only consider it according to what the compiler gives us ( Note that this config is just an idea and both it and the names can be changed and I would love to see other opinions. It would also be interesting to discuss a default configuration. |
I'm with @rafaelss95 on the simplified version. But I think that it would be easier to make it more visually organized if we could disitinguish between bindings and plain assignments, even if it means mixing inputs and attributes, similar to the suggestion on the issue I opened (#186) when i failed to realize this one already existed. |
@guilhermetod if I got your statement correctly, |
@rafaelss95 From the examples you gave, both <app-component
aria-label="app"
[attr.colspan]="colspanDefinedInTS"
class="lits-item--collapsed"
[inputValue]="inputValue"
></app-component> I would suggest separating binding (bracket syntax) and plain assignment (like the <app-component
aria-label="app"
class="lits-item--collapsed"
[attr.colspan]="colspanDefinedInTS" <!-- Group the bracket syntax -->
[inputValue]="inputValue"
></app-component> |
@guilhermetod Aha, I understand what you mean now!! Sorry about that, my example was wrong, thanks for noticing that. It should be correct now 😄 |
Thanks for such a blazing fast reaction guys.
But as you can see it can't be achieved at the moment.
I got your point @rafaelss95 @guilhermetod about sorting by brackets (kinda), looks good to me, unfortunately it's not what my team uses since this sorting will not help you to find components inputs, because they will be mixed with other |
Hey guys let's discuss default order and other stuff. #605 |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
It makes sense for structural directives like
*ngIf
to be first in the list of attributes:I don't promise anything, but if I have the time, I'll look into it this month.
P.S. Some issue templates could be useful. I'll also look into this.
P.S.2 Thanks for all the hard work!
The text was updated successfully, but these errors were encountered: