-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
fix(compiler): remove support for unassignable expressions in two-way bindings #55342
Conversation
@Input() value: any; | ||
@Output() valueChange = new EventEmitter<any>(); | ||
} | ||
describe('tsickle compatibility', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suite was accidentally nested under the two-way binding one.
… bindings Two-way bindings are meant to represent a property binding to an input and an event binding to an output, e.g. `[(ngModel)]="foo"` represents `[ngModel]="foo" (ngModelChange)="foo = $event"`. Previously due to a quirk in the template parser, we accidentally supported unassignable expressions in two-way bindings. In angular#54154 the quirk was fixed, but we kept support or some common expression because of internal usages. Now the internal usages have been cleaned up so the backwards-compatibility code can be deleted. Externally a migration was added in angular#54630 that will automatically fix any places that depended on the old behavior. BREAKING CHANGE: Angular only supports writable expressions inside of two-way bindings.
e89cabf
to
e3085bf
Compare
* | ||
* This option is only present to support an automated migration away from the invalid syntax. | ||
*/ | ||
allowInvalidAssignmentEvents?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit unfortunate that we need to keep this around a little while longer at the parser level, but it's not user-facing and the only place that enables it is the migration so once it is deleted, we can just drop it from here.
Passing TGP. Marking as blocked until the last set of cleanups have landed. |
Internal failures have been cleaned up, this should be ready to go. |
This PR was merged into the repository by commit 4eb0165. |
… bindings (angular#55342) Two-way bindings are meant to represent a property binding to an input and an event binding to an output, e.g. `[(ngModel)]="foo"` represents `[ngModel]="foo" (ngModelChange)="foo = $event"`. Previously due to a quirk in the template parser, we accidentally supported unassignable expressions in two-way bindings. In angular#54154 the quirk was fixed, but we kept support or some common expression because of internal usages. Now the internal usages have been cleaned up so the backwards-compatibility code can be deleted. Externally a migration was added in angular#54630 that will automatically fix any places that depended on the old behavior. BREAKING CHANGE: Angular only supports writable expressions inside of two-way bindings. PR Close angular#55342
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Two-way bindings are meant to represent a property binding to an input and an event binding to an output, e.g.
[(ngModel)]="foo"
represents[ngModel]="foo" (ngModelChange)="foo = $event"
. Previously due to a quirk in the template parser, we accidentally supported unassignable expressions in two-way bindings.In #54154 the quirk was fixed, but we kept support for some common expression because of internal usages. Now the internal usages have been cleaned up so the backwards-compatibility code can be deleted.
Externally a migration was added in #54630 that will automatically fix any places that depended on the old behavior.
BREAKING CHANGE:
Angular only supports writable expressions inside of two-way bindings.