-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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(upgrade): pass correct values to ngOnChanges
for interpolation bindings
#14301
fix(upgrade): pass correct values to ngOnChanges
for interpolation bindings
#14301
Conversation
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.
LGTM
@@ -78,17 +78,15 @@ export class DowngradeComponentAdapter { | |||
let expr: any /** TODO #9100 */ = null; | |||
|
|||
if (attrs.hasOwnProperty(input.attr)) { | |||
const observeFn = ((prop: any /** TODO #9100 */) => { | |||
const observeFn = (prop => { |
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.
Does the linter let you get away with an implicit any
here?
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 infers it is a string
(because input.prop
is a string
). No idea if/why it didn't before.
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.
oh it's an IIFE
…bindings Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions).
ac17c78
to
f5f3f8b
Compare
(Squashed the commits.) |
…bindings (angular#14301) Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions). PR Close angular#14301
@gkalpak this does not rebase on 2.4.x, if you would like me to merge it please create a new PR against that branch. |
…bindings Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions). This is the same as angular#14301, but for the 2.4.x branch.
…bindings Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions). This is the same as angular#14301, but for the 2.4.x branch.
…bindings (#14400) Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions). This is the same as #14301, but for the 2.4.x branch.
…bindings (angular#14301) Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions). PR Close angular#14301
…bindings (angular#14301) Previously, the `previousValue` and `currentValue` arguments passed to the `SimpleChange` constructor were swapped for interpolation bindings. This commit also refactors the code, so that interpolation bindings and property bindings share the same implementation, and fixes some broken tests (that hide failures by allowing the `$exceptionHandler` to swallow thrown exceptions). PR Close angular#14301
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. |
Please check if the PR fulfills these requirements
Docs have been added / updated (for bug fixes / features)What kind of change does this PR introduce? (check one with "x")
What is the current behavior? (You can also link to an open issue here)
The
previousValue
andcurrentValue
arguments passed to theSimpleChange
constructor are swapped for interpolation bindings.There are also some tests that may hide failures by allowing the
$exceptionHandler
to swallow thrown exceptions.What is the new behavior?
The
SimpleChange
objects are created correctly.Interpolation bindings and property bindings share the same implementation.
The tests no longer hide failures by swallowing exceptions.
Does this PR introduce a breaking change? (check one with "x")