Inconsistent behavior when returning Redirect object from canActivate() on navigate vs deep link page load

[jdanyow]

@landofjoe commented on Wed Aug 31 2016

I'm submitting a bug report

• Library Version: Aurelia-cli 0.18.0

Please tell us about your environment:

• Operating System: Windows 10
• Node Version: 5.9.0
• NPM Version: 3.10.6
• JSPM OR Webpack AND Version n/a
• Browser: all
• Language: all

Current behavior:

When implementing canActivate() in a child-routed view model, returning a new Redirect object results in the route being interpreted differently based on whether the route was loaded fresh (i.e. user loads the browser page directly to the route) or whether the route is navigated to (i.e. using router.navigate()).

   //this works from fresh page load, but not if you navigate to here
   canActivate(){
     return new Redirect("children/child1");
   }

   //this works if you navigate here using `router.navigate()`, but not for fresh page loads.
   canActivate(){
     return new Redirect("child1");
   }

Run the Gist (https://gist.host/run/1472695581644/index.html#/children/child1) View the Gist (https://gist.run/?id=0185b61c44d99f682ffbfb5479d3995d)

Expected/desired behavior:

There should be a consistent, reliable way to handle redirects from a child's canActivate() callback using the relative child route. (i.e. without having to hard code the parent route)

• What is the motivation / use case for changing the behavior?

Currently, it is difficult to cleanly handle redirects when users deep-link into part of an app. Because it is also possible to deep-link from within the app after it is already loaded, and that seems to have a different set of requirements.

[enrico-padovani]

Is there any progress with that? I'm facing the same problem in my application, so I cannot use redirect but just reject / throwing errors in order to cancel the route activation.

[Daniel-Glucksman]

+1