Repository navigation
cancelling routes #2109
Description
Activity
Locationchangestart event should do the trick if it doesn't then that's a bug. Can you repro this?
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.
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.
- added a commit that references this issue
on May 1, 2013 Calling $route.reload() in $routeChangeStart seems to prevent the route from changing.
Reacted by Aaditya KumarThe 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.
I tried $route.reload in $routeChangeStart but it seems to cause a loop and the page freezes (Angular 1.2.7).
@nickspacek I had the same problem. I resolved it by injecting
$locationand calling$location.url('original/path/1')instead of$route.reload()and it worked well. I think this is because by the time the$routeChangeStartevent 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
$locationChangeStartand$routeChangeStart. It'd be nice if they were in sync, I wonder if there's a reason to expose the naked URLs for the$locationChangeStartarguments instead of sugared JS objects.In my case, on
$routeChangeStart, I am sniffing thenextargument fornext.params.idto 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.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.
event.preventDefault()method in$routeChangeStartevent callback still doesn't prevent route change and actually does nothing$scope.$on('$routeChangeStart',function (event, next, current){ if(next.originalPath.indexOf('route1')!==-1){ console.log("I didn't prevent route change"); event.preventDefault(); } });$scope.$on("$locationChangeStart", function(event, nextUrl, currentUrl) { if(nextUrl.indexOf('route1')!==-1){ console.log('I prevented route change'); event.preventDefault(); } });as @zulrang said - I'm trying to do the exact same thing... big time bummer.
@OakBehringer can't you just add a
resolvedep that runs the check in routes that require authentication? as an added bonus you can offer your user object to the controller.We do this. I added a provider which the resolve property of the router utilizes. It tests a variety of auth conditions and either redirects the user to their destination or back to the login screen. We apply this provider to all routes and use API header authentication, combined with Rails sessions to allow a session to persist over multiple visits. At least... I think that's what we have, I'm definitely a UI guy.
Reacted by Matt ChinanderNothing helps me for v0.2.18.
There is currently no good/documented way of canceling a route change.
event.preventDefault()can be used with$locationChangeStartbut that event doesn't fire from the back button (bug?)$routeChangeStartdoes fire on back button, but itspreventDefault()method doesn't actually prevent the route from changing (bug?)Related issues: #592 #665 #1569