Expanding on the previous answer, utilizing [ ] and ( ) within HTML itself is incredibly descriptive of its functionality. Angular's core concept revolves around HTML components.
By breaking down the DOM into components, reusability is enhanced. When implementing such components (like angular material), it's essential for users importing them as libraries to understand the necessary @Input parameters and emitted @Output events. This way, when encountering these components in code, users can easily grasp how they operate.
Lack of proper representation leads to confusion for users. For example, check out this example.
With @Input and @Output:
<button mat-raised-button (click)="addColumn()"> Add column </button>
<button mat-raised-button (click)="removeColumn()"> Remove column </button>
<button mat-raised-button (click)="shuffle()"> Shuffle </button>
<table mat-table [dataSource]="data" class="mat-elevation-z8">
<ng-container [matColumnDef]="column" *ngFor="let column of displayedColumns">
<th mat-header-cell *matHeaderCellDef> {{column}} </th>
<td mat-cell *matCellDef="let element"> {{element[column]}} </td>
</ng-container>
<tr mat-header-row *matHeaderRowDef="columnsToDisplay"></tr>
<tr mat-row *matRowDef="let row; columns: columnsToDisplay;"></tr>
</table>
Without
<button mat-raised-button #add> Add column </button>
<button mat-raised-button #remove> Remove column </button>
<button mat-raised-button #shuffle> Shuffle </button>
<table mat-table class="mat-elevation-z8">
<ng-container *ngFor="let column of displayedColumns">
<th mat-header-cell *matHeaderCellDef> {{column}} </th>
<td mat-cell *matCellDef="let element"> {{element[column]}} </td>
</ng-container>
<tr mat-header-row *matHeaderRowDef="columnsToDisplay"></tr>
<tr mat-row *matRowDef="let row; columns: columnsToDisplay;"></tr>
</table>
Which code do you find more readable?
Additionally, consider how to handle simple events like (click), (keyup), or [routerLink].
While workarounds are possible, readability and developer-friendly practices should be maintained. Sometimes, segregating functionalities helps clarify their purpose within the codebase, a principle applicable across all software languages.