-
Notifications
You must be signed in to change notification settings - Fork 26.2k
feat(router): allow passing an ActivatedRouteSnapshot for relative link resolution in Router.createUrlTree #43800
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
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, just one nit on a misspelled variable. Thanks for the addition!
b03608d
to
266bea0
Compare
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 🍪
This looks good aside from a typo in a variable name.
reviewed-for: public-api
…nk resolution in Router.createUrlTree The relativeTo property of the navigationExtras parameter in the createUrlTree method of the Router class may now be an ActivatedRoute or an ActivatedRouteSnapshot. The latter is useful in CanActivate route guards when building an alternative UrlTree to navigate to, relative to the URL that the current navigation is attempting to access. BREAKING CHANGE: The relativeTo property of the UrlCreationOptions interface in the router package may now also be an ActivatedRouteSnapshot. The relativeTo property is now typed `ActivatedRoute | ActivatedRouteSnapshot | null`. Code accessing relativeTo may have to account for the possiblity this property is an ActivatedRouteSnapshot. Fixes angular#22763
266bea0
to
6b1c7ef
Compare
@daiscog Can you write a few tests that actually verify the creation behavior in a guard? The |
@atscott The point is not to replace part of the current UrlTree, but rather to replace the entire current UrlTree with an absolute path derived from resolving a relative URL against the pending navigation. A simple, contrived example: Navigating from Guard for the latter wants to redirect to If you still think it is necessary, I will take the time to try to codify these expectations in some tests? |
@daiscog Yes, I understand what you're saying, but that's not how the code in
As I said before, because the |
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.
Setting my review to request changes to add test cases. From my recent investigations in this area, I unfortunately don't think this will actually achieve the intended goal.
An alternative could be to expose a standalone method that creates a UrlTree
from an ActivatedRoute
/ActivatedRouteSnapshot
without the urlTree: UrlTree
parameter that's in this function. This should be possible but would require quite a bit of work and testing.
Hi @atscott No problem, thanks for the extra info. I'll see if I can get time to work some more on this at the weekend. Cheers, Dai |
Closing due to #43800 (comment). I don't believe this will actually work based on how the code is structured now. Feel free to open a new PR if you have a test that proves me wrong. |
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. |
The relativeTo property of the navigationExtras parameter in the createUrlTree method of the Router class may now be an ActivatedRoute or an ActivatedRouteSnapshot.
The latter is useful in CanActivate route guards when building an alternative UrlTree to navigate to, relative to the URL that the current navigation is attempting to access.
Fixes #22763
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?
As reported in Issue Number: #22763, when implementing a CanActivate route guard, there is no way to return a UrlTree relative to the route that would otherwise have been activated, as the current ActivatedRoute is the previous navigation, and the next navigation is only available via the ActivatedRouteSnapshot given to the guard.
What is the new behavior?
This change allows passing an ActivatedRouteSnapshot to as the relativeTo value, thus enabling the following pattern in a route guard:
Does this PR introduce a breaking change?