Skip to content

Conversation

@mhevery
Copy link
Contributor

@mhevery mhevery commented Mar 9, 2017

Closes #15020

Showing the new and the equivalent old syntax.

  • *ngIf="exp as var1”
    => *ngIf="exp; let var1 = ngIf”
  • *ngFor="var item of itemsStream |async as items”
    => *ngFor="var item of itemsStream |async; let items = ngForOf”

@mprobst
Copy link
Contributor

mprobst commented Mar 9, 2017

Can we avoid using as? It overlaps with TS casts, that'll be quite confusing for users.

@Toxicable
Copy link

Toxicable commented Mar 9, 2017

@mprobst as pointed out here #15020 (comment) ES2015 uses it very much in the same way as to the proposed way here, also I do challenge you to find a more fitting word

@mprobst
Copy link
Contributor

mprobst commented Mar 9, 2017

@Toxicable yeah, the ES6 imports are a point, but that's more of a renaming situation (and also more similar to casts), where this looks to me more like an assignment.

We couldn't make *ngIf="var1 = exp” work, could we? That'd also match JS syntax, module introducing a new symbol: if (var1 = exp) { ... use var1 ... }.

@Toxicable
Copy link

@mprobst As explained here #15020 (comment) and in the comment following it explains that let user = foo already has meaning in Angular

@mprobst
Copy link
Contributor

mprobst commented Mar 9, 2017

I wonder if we could use a different symbol to make the assignment more clear and remove the overlap? let foo := expr? In any case, I'm probably just adding noise here, sorry ;-)

@johanchouquet
Copy link
Contributor

If the as keyword is a problem, why not changing to be ? The intent is very clear and it is not used in Typescript nor JS IMHO: *ngIf="exp as var1” => *ngIf="exp be var1” >> => *ngIf="exp; let var1 = ngIf”

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so both let i=index and index as i are supported, right? do you think it's a good idea to have multiple ways to do the same thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we take away let then we break a whole lot of people. So, yes both will be supported.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we discussed this after this comment was posted and decided that we do want to remove the old way. @mhevery did I understand the conclusion of the conversation correctly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should add a console warning that let syntax is deprecated (similar to template element) so it will be easier to remove it in v5

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old way can't be removed as it would break a lot of people. Think *ngFor="let item of items" What was discussed was to remove *ngIf="exp; let var" However, it turns out that can't be removed either as it would make the else statement weird.

So in summary. Old syntax is supported but the new syntax is preferred. Both will continue to work.

@mhevery mhevery force-pushed the as_syntax branch 4 times, most recently from 3022f82 to 4787d03 Compare March 9, 2017 20:05
Copy link
Contributor

@IgorMinar IgorMinar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️ 👍 🦄 🌈

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we discussed this after this comment was posted and decided that we do want to remove the old way. @mhevery did I understand the conclusion of the conversation correctly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I LOVE that the as can be used for all the local variables. It makes the whole syntax look so much more consistent and cleaner. ❤️

@IgorMinar
Copy link
Contributor

With regards to the as conflict with typescript, as others mentioned the conflict already exists with ESM aliasing. Our semantics of as are consistent with that of ESM aliasing and therefor, I don't think that we should be dismissing as on the basis of the typescript conflict.

It's also worthwhile keeping in mind that nowhere in Angular templates we use types or have affordances for explicit type position in the syntax, so I that's another argument why the as conflict is a non-issue in my opinion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look right to me as it is much more lax in the syntax than you probably intent. You probably meant this to be !this.next.isOperator(chars.$SEMICOLON) && !this.next.isOperator(chars.$COMMA) && because optionalCharacter will advance the token which appears not what you intended.

If you make the above change you need to undelete line 717 an put it after your block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

mhevery added 4 commits March 10, 2017 17:08
Closes angular#15020

Showing the new and the equivalent old syntax.
- `*ngIf="exp as var1”`
   => `*ngIf="exp; let var1 = ngIf”`
- `*ngFor="var item of itemsStream |async as items”`
   => `*ngFor="var item of itemsStream |async; let items = ngForOf”`
@mhevery mhevery added the action: merge The PR is ready for merge by the caretaker label Mar 14, 2017
@chuckjaz chuckjaz merged commit c10c060 into angular:master Mar 15, 2017
d-koppenhagen added a commit to angular-buch/book-monkey2 that referenced this pull request Mar 23, 2017
@mhevery mhevery deleted the as_syntax branch June 2, 2017 17:01
asnowwolf pushed a commit to asnowwolf/angular that referenced this pull request Aug 11, 2017
* feat(common): support `as` syntax in template/* bindings

Closes angular#15020

Showing the new and the equivalent old syntax.
- `*ngIf="exp as var1”`
   => `*ngIf="exp; let var1 = ngIf”`
- `*ngFor="var item of itemsStream |async as items”`
   => `*ngFor="var item of itemsStream |async; let items = ngForOf”`

* feat(common): convert ngIf to use `*ngIf="exp as local“` syntax

* feat(common): convert ngForOf to use `*ngFor=“let i of exp as local“` syntax

* feat(common): expose NgForOfContext and NgIfContext
@abdel-ships-it
Copy link

Why is this limited to ngFor and ngIf?

@tytskyi
Copy link

tytskyi commented Aug 24, 2017

@realappie it is not limited, if you write your own structural directive it will work there

juleskremer pushed a commit to juleskremer/angular that referenced this pull request Aug 28, 2017
* feat(common): support `as` syntax in template/* bindings

Closes angular#15020

Showing the new and the equivalent old syntax.
- `*ngIf="exp as var1”`
   => `*ngIf="exp; let var1 = ngIf”`
- `*ngFor="var item of itemsStream |async as items”`
   => `*ngFor="var item of itemsStream |async; let items = ngForOf”`

* feat(common): convert ngIf to use `*ngIf="exp as local“` syntax

* feat(common): convert ngForOf to use `*ngFor=“let i of exp as local“` syntax

* feat(common): expose NgForOfContext and NgIfContext
@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 Sep 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: merge The PR is ready for merge by the caretaker cla: yes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RFC: as local-val syntax proposal

10 participants