Conversation
cd2e2ab to
de2b943
Compare
de2b943 to
ae042ba
Compare
d8d8e31 to
c344e24
Compare
97dd35f to
bc3118b
Compare
|
I see that you just added the If you want your PR to be merged, it has to pass all the CI checks. If you can't get the PR to a green state due to flakes or broken |
AndrewKushnir
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
goldens/public-api/core/errors.md
Outdated
There was a problem hiding this comment.
Should this change, or should error codes be permanent? (even if they're not documented?)
There was a problem hiding this comment.
I'm happy to revert this. I think I had the same question in the past and I was informed that we do not commit to keeping the error codes stable. @AndrewKushnir @alxhub
There was a problem hiding this comment.
I'm going to revert this error code change because I also agree with there being value in keeping them stable. Even if we decide in the meeting that it's not something we will do, there's really no reason to change it in this PR.
There was a problem hiding this comment.
+1 to keep error codes stable (this is the main point of having golden files for them). I was under impression that those code represent similar conditions under which the error occurs, thus the change was ok. If it's not the case, let's keep the code stable.
89d8cf7 to
c6b59c0
Compare
jelbourn
left a comment
There was a problem hiding this comment.
LGTM for now on the error code, but I added an item to the team meeting agenda to discuss at some point (I feel like there's some value in keeping them stable)
Reviewed-for: public-api
c6b59c0 to
a87a3e1
Compare
|
This PR was merged into the repository by commit dfcf0d5. |
…52455) The `afterRender` hooks currently run after `ApplicationRef.tick` but also run after any call to `ChangeDetectorRef.detectChanges`. This is problematic because code which uses `afterRender` cannot expect the component it's registered from to be rendered when the callback executes. If there is a call to `ChangeDetectorRef.detectChanges` before the global change detection, that will cause the hooks to run earlier than expected. This behavior is somewhat of a blocker for the zoneless project. There is plenty of application code that do things like `setTimeout(() => doSomethingThatExpectsComponentToBeRendered())`, `NgZone.onStable(() => ...)` or `ApplicationRef.onStable...`. `ApplicationRef.onStable` is a should likely work similarly, but all of these are really wanting an API that is `afterRender` with the requirement that the hook runs after the global render, not an individual CDRef instance. This change updates the `afterRender` hooks to only run when `ApplicationRef.tick` happens. fixes #52429 fixes #53232 PR Close #52455
…ngular#52455) The `afterRender` hooks currently run after `ApplicationRef.tick` but also run after any call to `ChangeDetectorRef.detectChanges`. This is problematic because code which uses `afterRender` cannot expect the component it's registered from to be rendered when the callback executes. If there is a call to `ChangeDetectorRef.detectChanges` before the global change detection, that will cause the hooks to run earlier than expected. This behavior is somewhat of a blocker for the zoneless project. There is plenty of application code that do things like `setTimeout(() => doSomethingThatExpectsComponentToBeRendered())`, `NgZone.onStable(() => ...)` or `ApplicationRef.onStable...`. `ApplicationRef.onStable` is a should likely work similarly, but all of these are really wanting an API that is `afterRender` with the requirement that the hook runs after the global render, not an individual CDRef instance. This change updates the `afterRender` hooks to only run when `ApplicationRef.tick` happens. fixes angular#52429 fixes angular#53232 PR Close angular#52455
…ngular#52455) The `afterRender` hooks currently run after `ApplicationRef.tick` but also run after any call to `ChangeDetectorRef.detectChanges`. This is problematic because code which uses `afterRender` cannot expect the component it's registered from to be rendered when the callback executes. If there is a call to `ChangeDetectorRef.detectChanges` before the global change detection, that will cause the hooks to run earlier than expected. This behavior is somewhat of a blocker for the zoneless project. There is plenty of application code that do things like `setTimeout(() => doSomethingThatExpectsComponentToBeRendered())`, `NgZone.onStable(() => ...)` or `ApplicationRef.onStable...`. `ApplicationRef.onStable` is a should likely work similarly, but all of these are really wanting an API that is `afterRender` with the requirement that the hook runs after the global render, not an individual CDRef instance. This change updates the `afterRender` hooks to only run when `ApplicationRef.tick` happens. fixes angular#52429 fixes angular#53232 PR Close angular#52455
…ngular#52455) The `afterRender` hooks currently run after `ApplicationRef.tick` but also run after any call to `ChangeDetectorRef.detectChanges`. This is problematic because code which uses `afterRender` cannot expect the component it's registered from to be rendered when the callback executes. If there is a call to `ChangeDetectorRef.detectChanges` before the global change detection, that will cause the hooks to run earlier than expected. This behavior is somewhat of a blocker for the zoneless project. There is plenty of application code that do things like `setTimeout(() => doSomethingThatExpectsComponentToBeRendered())`, `NgZone.onStable(() => ...)` or `ApplicationRef.onStable...`. `ApplicationRef.onStable` is a should likely work similarly, but all of these are really wanting an API that is `afterRender` with the requirement that the hook runs after the global render, not an individual CDRef instance. This change updates the `afterRender` hooks to only run when `ApplicationRef.tick` happens. fixes angular#52429 fixes angular#53232 PR Close angular#52455
|
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. |
he
afterRenderhooks currently run afterApplicationRef.tickbutalso run after any call to
ChangeDetectorRef.detectChanges. This isproblematic because code which uses
afterRendercannot expect thecomponent it's registered from to be rendered when the callback
executes. If there is a call to
ChangeDetectorRef.detectChangesbeforethe global change detection, that will cause the hooks to run earlier
than expected.
This behavior is somewhat of a blocker for the zoneless project. There
is plenty of application code that do things like
setTimeout(() => doSomethingThatExpectsComponentToBeRendered()),NgZone.onStable(() => ...)orApplicationRef.onStable....ApplicationRef.onStableshould likely work similarly, but all of these are really wanting an API
that is
afterRenderwith the requirement that the hook runs after theglobal render, not an individual CDRef instance.
This change updates the
afterRenderhooks to only run whenApplicationRef.tickhappens.fixes #52429
fixes #53232