frontend-handbook
frontend-handbook copied to clipboard
Add naming convention table
I think we could move this to some framework-agnostic part, this makes sense for Angular as well
I think we could move this to some framework-agnostic part, this makes sense for Angular as well
@fvoska I was thinking the same thing, but... What should I do with the Note part? Do you have something similar to polymorphic component in Angular?
@isBatak we don't have polymorphic components, but in the example of button link component that can be rendered either as a button
or a
, in Angular it is solved by using attribute selector instead of element selector for things like button/link component. Example for material button that can be applied to both button and anchor:
Will use material button styles, render a
and set href and trigger router navigation on click:
(this is the preferred way for routing)
<a mat-button routerLink="/home">Go home</a>
Will use material button styles, render button
and trigger router navigation on click:
(this is not the preferred way because you can not, for example, open link in new tab since it's not a
with href
)
<button mat-button routerLink="/home">Go home</button>
Just regular button that does some action, not navigation:
<button mat-button (click)="doSomething()">Do something</button>
Concerns are split up between two directives - mat-button
and routerLink
and they can be applied both independently and at the same time if necessary, to both a
and button
elements. I know that the naming is inconsistent - one is kebab-case and the other pascalCase. That is because angular core and angular material are not always following the same naming conventions
In almost all cases you would use a
if you are doing navigation, but you apply the button styles in the same way for both button and anchor.
So, this kind of thing is solved in a different way in Angular. You can apply many directives to same host element and that is the way how you compose together many functionalities that are independent. For example, you could add some tooltip directive as well.
For regular components we can apply pretty much the same naming convention as what you proposed. We can document framework-specific edge cases in sub-chapters for Angular and React, but I think that the naming table applies for both frameworks
@isBatak this has been opened for a while. I am fine with the proposal, so if there are no additional comments from others, I think we can merge.
@fvoska thx, let me just check it on staging one more time