cancelling routes

[geddski]

There is currently no good/documented way of canceling a route change.

event.preventDefault() can be used with $locationChangeStart but that event doesn't fire from the back button (bug?)

$routeChangeStart does fire on back button, but its preventDefault() method doesn't actually prevent the route from changing (bug?)

Related issues: #592 #665 #1569

[IgorMinar]

Locationchangestart event should do the trick if it doesn't then that's a bug. Can you repro this?

[geddski]

Yep - http://plnkr.co/edit/NycOKi?p=preview

[geddski]

I'm playing around with simulating a back button in the locationSpec, but it's having no effect on $location.url():

$location.url() // 'somePath'
$window.history.go(-1);
$location.url() // 'somePath' still
$window.history.back();
$location.url() // 'somePath' still

Maybe that's part of the problem.

[DanWahlin]

Any idea when this will make into one of the "unstable" builds? This is a show stopper when a controller needs to track dirty data and prevent navigation away from a view (or at least prompt the user). Thanks for the fix though quazzie.

[reichertm]

Calling $route.reload() in $routeChangeStart seems to prevent the route from changing.

[WhatFreshHellIsThis]

The event $locationChangeStart has as it's second parameter the 'next' route but all it shows is the full path: "http://localhost:3000/#/users" Surely if you expect people to use this to cancel routes it should include only the /users (for example) part of the path as $routeChangeStart event does with it's 'originalPath' property.

Right now we're forced to parse the URL to use this.

These inconsistencies need to be cleaned up, they make it a nightmare to learn angular.

[nickspacek]

I tried $route.reload in $routeChangeStart but it seems to cause a loop and the page freezes (Angular 1.2.7).

[bradgreens]

@nickspacek I had the same problem. I resolved it by injecting $location and calling $location.url('original/path/1') instead of $route.reload() and it worked well. I think this is because by the time the $routeChangeStart event fires, the Angular internals have updated a property to the new route and $route.reload() continuously reloads the new route regardless if you're trying to prevent it from happening.

As @WhatFreshHellIsThis mentioned there are inconsistencies with the arguments for $locationChangeStart and $routeChangeStart. It'd be nice if they were in sync, I wonder if there's a reason to expose the naked URLs for the $locationChangeStart arguments instead of sugared JS objects.

In my case, on $routeChangeStart, I am sniffing the next argument for next.params.id to determine if the user is allowed to access a manually entered URL hash.

The downside to my $location.url() solution is that it triggers a page transition while returning to the same page.

[zulrang]

I'm having a similar issue where I want to authenticate the route change by examining the sugared next parameter and cancelling the route change in the case where the user isn't authorized.

This seems like a very basic feature that should have a clean solution.