angular: Router no longer navigates when navigating to the current URL.

The router is a state machine.

Being able to navigate to the “current state” might lead to confusing behaviour. For example, consider this scenario:

• The current state is A
• I’m navigating to A
• A guard rejects the navigation
• I’m supposed to go back to the current state, which is A, which I’m no longer allowed to navigate to. Sort of.

This seems like an end developer error, but yes, if a guard rejects navigation then stay where you are and do nothing else.

Also, we are considering rerunning resolvers every time a navigation happens, which won’t work with your use case as well.

I guess it would depend on runGuardsAndResolvers setting.

I think we should either always allow it, or never allow it, so don’t have an extra option.

How about at least 2, maybe 3 ways to set this 😃

• A module level strategy

and one or both of the following to override module level setting:

• A new route setting in ExtraOptions to be set at route definition
• A setting in routerLink and navigate() to be set a call site

Why navigate to same route

I think this is what most everyone expects, end users and developers alike. My specific use case is for settings screens like the one in github.

If you click Options on the left, pretty much everyone expects the form to reset (and usually with updated data if there are updates). The same with Settings up top (except it would also take you back to Options if you were on a different settings page). Ideally, there shouldn’t be anything (or very little) a dev has to do to get this behavior.

@Kriskit Firing some sort of event is a good idea. Maybe “IgnoredNavigation” or something like that.

I would love to see this reviewed again. The IgnoredNavigation event would work well for our use case.

The router is a state machine.

Being able to navigate to the “current state” might lead to confusing behaviour. For example, consider this scenario:

• The current state is A
• I’m navigating to A
• A guard rejects the navigation
• I’m supposed to go back to the current state, which is A, which I’m no longer allowed to navigate to. Sort of.

Also, we are considering rerunning resolvers every time a navigation happens, which won’t work with your use case as well.

I think we should either always allow it, or never allow it, so don’t have an extra option.

Is it just the scrolling you are concerned about? If so, maybe it’s better to have a directive with this selector [routerLink] that will force the scrolling?

As far as I can see, this issue is closed, but the “navigations” Observable in the router is private. Is there another feature request or way of allowing a end-user to listen to navigation.

My use case is a single component (enclosing an iframe) that needs to reset its state (iframe’s URL) when the user clicks on a link toward the current page. Having a directive override [routerLink] for my whole application seems a bit overkill…

In my case, being able to override onSameUrlNavigation on a per-route basis would be perfect (actually)…

It looks like the NavigationStart event occurs after urlHandlingStrategy.shouldProcessUrl(rawUrl), I have been of the school of thought that you fire a start event then you do stuff, in this implementation stuff is done (shouldProcessUrl) before the start event. NavigationStart should be renamed to RoutingStart and NavigationStart should fire immediately after any navigation event.

I understand what you’re saying but it still feels like the router should at least tell us something, even if it was a NavigationCancel event. At present, despite a call being made to the router to navigate (through a [routerLink] click or otherwise) no events get fired at all.

I’m not convinced using a [routerLink] selector directive would cover everything I need it to do but I will give it a try, although feels like a workaround.

This used to work fine, and saw nothing in the change logs to suggest there was a breaking change regarding this so viewed it as a bug.