Angular expressions should be plain TypeScript expressions #43485
Comments
|
Could this enhancement for the compiler be included too? #43253 |
That appears to be unrelated to Angular's expression syntax, as it's a request for more accurate type-checking. So we'll keep that one separate. |
|
Really looking forward to seeing this completed! Not having |
|
(edited for grammar errors) I hope this helps. There are some cases where features like arrow functions could be used instead of features like - <button (click)="fire($event)">Click me!<button>
+ <button [onclick]="fire">Click me!<button> <!-- where `fire` is an arrow function that accepts the native event object -->Component: - @Output() onIncr = EventEmitter<number>()
+ @Input() onIncr: (x: number) => voidNow that I think about it, I think Treating outputs as inputs can also allow more output parameters per attribute, shallow out the learning curve, and facilitate spread props (see #14545), especially with multiple wrapping children. Regarding pipes, I don't think they're necessary as (I think) Angular is built on the concept of separation of concerns (i.e. templates are for light to no computations, and components and services are for medium to heavy computations), and removing the pipe operator will also decrease the API surface and remove two tokens to check for ( 5 |> x2 |> console.log // => 10However, I can no longer find the examples on MDN. |
Ok, I can see why my comment got a thumbs down. Without the (banana) syntax, there is not a way to implement two-way binding unless devs are okay with thiis: <input [ngModel]="name" [onNgModelChange]="newName => (name = newName)">Maybe the banana syntax could translate to the example above: <input (ngModel)="name">That will need further discussion. |
|
On a separate note, I like the structural directive micro-syntax a lot; at first, it made think that <input [ngModel]="name; onChange: newName => (name = newName)">could be mapped to this: <input [ngModel]="name" [ngModelOnChange]="newName => (name = newName)">...under the hood. |
Which @angular/* package(s) are relevant/releated to the feature request?
compiler
Description
This issue is a container for all the issues that have requested new expression syntax features.
The aim is to collect all the features into one place so that we can track the work.
The plan is to do an holistic analysis of the syntax and decide things like:
The result will be a project proposal for the changes that we would like to make to the syntax in the short to medium term.
Related Issues
|) operator has incorrect precedence (too tight) #27415The text was updated successfully, but these errors were encountered: