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(core): Ensure backwards-referenced transplanted views are refreshed #51854
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.
reviewed-for: public-api
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.
reviewed-for: public-api
dbb2283
to
0cd776b
Compare
/** | ||
* The maximum number of times the change detection traversal will rerun before throwing an error. | ||
*/ | ||
const MAXIMUM_REFRESH_RERUNS = 100; |
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.
As far as I remember we were discussing lowering this number?
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.
I do not recall this conversation. But the number is an arbitrary decision by me. I have no opinions on what it should be.
This commit runs change detection in a loop while there are still dirty views to be refreshed in the tree. At the moment, this only applies to transplanted views but will also apply to views with changed signals. fixes angular#49801
0cd776b
to
14734ac
Compare
caretaker: green TGP, current failures are existing failures |
This PR was merged into the repository by commit 76152a5. |
…tion The significance of the combination of angular#51854 and angular#52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes angular#50320
…tion The significance of the combination of angular#51854 and angular#52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes angular#50320
…tion The significance of the combination of angular#51854 and angular#52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes angular#50320
…tion The significance of the combination of angular#51854 and angular#52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes angular#50320
…tion The significance of the combination of angular#51854 and angular#52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes angular#50320
…tion (#52476) The significance of the combination of #51854 and #52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes #50320 PR Close #52476
…tion (#52476) The significance of the combination of #51854 and #52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes #50320 PR Close #52476
…tion (angular#52476) The significance of the combination of angular#51854 and angular#52302 went mostly unnoticed. The first removed a unidirectional data flow constraint for transplanted views and the second updated the signal implementation to share transplanted view logic. The result is that we automatically get behavior that (mostly) removes `ExpressionChangedAfterItWasCheckedError` when signals are used to drive application state to DOM synchronization. fixes angular#50320 PR Close angular#52476
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. |
…ed (angular#51854) This commit runs change detection in a loop while there are still dirty views to be refreshed in the tree. At the moment, this only applies to transplanted views but will also apply to views with changed signals. fixes angular#49801 PR Close angular#51854
…ed (angular#51854) This commit runs change detection in a loop while there are still dirty views to be refreshed in the tree. At the moment, this only applies to transplanted views but will also apply to views with changed signals. fixes angular#49801 PR Close angular#51854
Based off of https://github.com/angular/angular/pull/51515This commit runs change detection in a loop while there are still dirty
views to be refreshed in the tree. At the moment, this only applies to
transplanted views but will also apply to views with changed signals.
fixes #49801