I had the feeling that the preferred way of redirecting was to return a UrlTree from the guard rather than imperatively navigating from the guard.
How would we get this behavior when returning a UrlTree?

Also, I must say that using UrlTrees is quite confusing, especially for beginners. Common navigations (using routerLink or router.navigate) use strings or arrays of segments to navigate, but in order to redirect, we have to transform the string/array into a UrlTree, which is not intuitive.
Even with the current state of this PR, if the goal is to keep the currently requested URL, couldn't we simply pass a boolean option rather than an UrlTree option?

I had the feeling that the preferred way of redirecting was to return a UrlTree from the guard rather than imperatively navigating from the guard.

Yes, redirects should generally go through that mechanism. router.navigate...; return false isn't a true redirect as far as the Router's concerned. It's a new navigation that cancels and supersedes the current one. Redirects with the UrlTree return allow you to keep the original Promise from navigate and not resolving it until the redirect navigation completes. We can track it more directly as an actual redirect and treat it as a direct continuation of the initial navigation.

How would we get this behavior when returning a UrlTree?

It should and will be available, but I didn't feel that this feature needed to be blocked on having that available.

Unfortunately the UrlTree redirects don't provide a way to defined extras and was a design decision at the time (#27148 (comment)). I think it's clear now that this wasn't right and it'll be available in v18 with #45023 (expanding the type is a breaking change).

Also, I must say that using UrlTrees is quite confusing, especially for beginners. Common navigations (using routerLink or router.navigate) use strings or arrays of segments to navigate, but in order to redirect, we have to transform the string/array into a UrlTree, which is not intuitive.

Agreed. There are at least two reasons this PR is still in draft mode and one of them is that I'm not yet decided on the behavior here with urlHandlingStrategy and urlSerializer (that includes string as an option). At the moment, I'm leaning towards not serializing a string and not using UrlHandlingStrategy.merge with the property value. In this way, the browserUrl property can also be used as a way to manually avoid UrlHandlingStrategy behavior.

Even with the current state of this PR, if the goal is to keep the currently requested URL, couldn't we simply pass a boolean option rather than an UrlTree option?

Two things here: It is a goal but I wouldn't say it's necessarily the only goal. The feature as proposed here is a lot more flexible than a boolean and could be used for other use-cases. Additionally, as described above, the router.navigate...; return false; pattern isn't really a redirect. I don't think a boolean directly in the navigation extras that depends on the current router/navigation state (if there is one) is a great API. That said, I do think we could consider a shortcut to getting this behavior with a boolean when RedirectCommand is available since that, by definition, is only working in the context of an actual redirect.

Thanks for the detailed explanations @atscott

Thank you so much for building this @atscott ! We'll be using this the second it get's released.

This PR was merged into the repository by commit 1d3a752.

The changes were merged into the following branches: main

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}