feat(router): Add ability to create UrlTree from any ActivatedRouteSnapshot#45877
feat(router): Add ability to create UrlTree from any ActivatedRouteSnapshot#45877atscott wants to merge 4 commits intoangular:mainfrom
UrlTree from any ActivatedRouteSnapshot#45877Conversation
UrlTree from any `ActivatedRout…UrlTree from any ActivatedRouteSnapshot
4e3cc60 to
afc95ad
Compare
afc95ad to
39baf5c
Compare
|
Shouldn't we deprecate the 'old way' right away, so that it can be eventually deleted sooner rather than later? |
|
@alfaproject The "old way" will be replaced with this new function as a breaking change rather than deprecating it. That is, the |
39baf5c to
62b9065
Compare
…eSnapshot` This exposes a new function from the router public API that allows developers to create a `UrlTree` from _any_ `ActivatedRouteSnapshot`. The current Router APIs only support creating a `UrlTree` from an `ActivatedRoute` which is both active _and_ materially appears in the `UrlTree` (it cannot be an empty path named outlet). This is because the implementation of the current way of creating a `UrlTree` attempts to look up the `UrlSegment` of the `ActivatedRoute` in the currently active `UrlTree` of the router. When this doesn't work, the `UrlTree` creation fails. Note that this API does not replace the current one. That would actually be a breaking change but should be done at some point in the future (v15). That is, `router.navigate` should call this new function. At that point, we can remove `_lastPathIndex`, `_urlSegment`, and `_correctedPathIndex` from the `ActivatedRoute`, along with all of the logic associated with determining what those should be. In addition, this would unblock a fix for angular#26081 because the `applyRedirects` and `recognize` operations could be combined into one. Overall, this would simplify logic in the router and reduce code size. It also exposes core routing capabilities as a helper function which were previously private API, which is a necessary step towards angular#42953. As a stress test for this new function, it _was_ swapped in as the default for `UrlTree` creation in angular#45859 and tested internally. The results indicate that this function behaves correctly. resolves angular#42191 (Tested directly) resolves angular#38276 (The test with a guard covers this case) resolves angular#22763 (Tested directly)
62b9065 to
37403d9
Compare
…tedRouteSnapshot`
…tedRouteSnapshot`
AndrewKushnir
left a comment
There was a problem hiding this comment.
Just for additional context: we discussed the commands argument question offline. The summary is that it's a well established term in Router APIs and this API has symmetry with other APIs. The changes looks great 👍
AndrewKushnir
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
jessicajaniuk
left a comment
There was a problem hiding this comment.
reviewed-for: public-api
…tedRouteSnapshot`
|
caretaker note: Most of the changes are part of the new API and only minimally touches existing router code. For a router change, this is comparatively low risk but if you could merge and sync on its own or other low risk PRs, that would be a good idea. |
|
This PR was merged into the repository by commit 53ca936. |
|
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. |
This exposes a new function from the router public API that allows
developers to create a
UrlTreefrom anyActivatedRouteSnapshot.The current Router APIs only support creating a
UrlTreefrom anActivatedRoutewhich is both active and materially appears in theUrlTree(it cannot be an empty path named outlet). This is because theimplementation of the current way of creating a
UrlTreeattempts tolook up the
UrlSegmentof theActivatedRoutein the currently activeUrlTreeof the router. When this doesn't work, theUrlTreecreationfails.
Note that this API does not replace the current one. That would actually be a
breaking change but should be done at some point in the future (v15). That is,
router.navigateshould call this new function. At that point, we canremove
_lastPathIndex,_urlSegment, and_correctedPathIndexfromthe
ActivatedRoute, along with all of the logic associated withdetermining what those should be. In addition, this would unblock a fix
for #26081 because the
applyRedirectsandrecognizeoperationscould be combined into one. Overall, this would simplify logic in the router
and reduce code size. It also exposes core routing capabilities as a helper function
which were previously private API, which is a necessary step towards #42953.
As a stress test for this new function, it was swapped in as the
default for
UrlTreecreation in #45859 and tested internally. Theresults indicate that this function behaves correctly.
resolves #42191 (Tested directly)
resolves #38276 (The test with a guard covers this case)
resolves #22763 (Tested directly)