fix(router): Pass correct component to canDeactivate checks when using two sibling router-outlets#36302
fix(router): Pass correct component to canDeactivate checks when using two sibling router-outlets#36302martinsik wants to merge 1 commit into
Conversation
|
The failing test is because the bundle size increased but it looks like the expected size was already outdated. It expects |
|
global presubmit passed |
|
As for the size failure, those need to be updated every once in a while. Lucky PR authors increase the size just enough to break the 500B threshold and have to update the |
225d5bf to
f505eaa
Compare
|
I had to rebase to master and rerun |
|
@martinsik - thanks for the update. The formatting changes are expected as clang format was just updated in c5c57f6. |
atscott
left a comment
There was a problem hiding this comment.
Just two nits to remove null assertion operator now that the type includes null
|
FYI - I also just ran the size test locally at master and got 226611 for the size so the increase is only 48 between the PR and master. |
kara
left a comment
There was a problem hiding this comment.
LGTM for size changes (given that it's only 48)
…g two or more sibling router-outlets (#36302) fixes #34614 There's an edge case where if I use two (or more) sibling <router-outlet>s in two (or more) child routes where their parent route doesn't have a component then preactivation will trigger all canDeactivate checks with the same component because it will use wrong OutletContext. PR Close #36302
…hen using two or more sibling router-outlets (angular#36302)" This reverts commit 80e6c07.
|
Hi @martinsik - A failure was detected internally so this PR is being rolled back in #36697. I added a test in #36699 to cover the failing use-case. |
|
@atscott Should I open another PR when that test is merged and I fix this PR? |
|
Hey @martinsik yes please if you could rebase + update this PR with the test that Andrew provided then we can reland this fix. |
This PR adds test case to cover a failure that was detected after merging angular#36302. That commit will be reverted and will need a new PR that does not cause this test to fail.
|
@martinsik - sorry that this PR got stuck. Could you rebase on master to check that it is still working after the new test was added, and to resolve the conflict? Then I think we should be able to land it. |
|
Actually this PR has been resolved via other commits. |
|
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. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #34614
There's an edge case where if I use two (or more) sibling
<router-outlet>s in two (or more) child routes where their parent route doesn't have a component then preactivation will trigger allcanDeactivatechecks with the same component because it will use wrongOutletContext.Navigating from
'/a/(b1//aux:b2)'to'/c'will call bothcanDeactivateguards withBlankCmp.Replication steps are described in #34614.
Updated demo for Angular 9: https://stackblitz.com/edit/angular-named-outlet-enygni?file=app%2Fapp.component.html
What is the new behavior?
canDeactivatecheck is called with correct component.Does this PR introduce a breaking change?
Other information
This fix will pass extra parameter to
deactivateRouteAndItsChildrenthat is used in case a route is without a component because there's probably no other way to determine the correctOutletContextbeforehand. The child routers are iterated insidedeactivateRouteAndItsChildrenwhere it can access only childOutletContexts. However, in this case the router-outlets are siblings.