Cancelling a navigation instruction with a redirect raises inconsistent navigation events
I've tested the new navigation events (processing -> success|error|canceled -> compete) using the routing pipeline steps as described in the documentation, but the new router does not seem to raise consistent events when redirecting from a pipeline step.
When redirecting from /welcome to /login in the authorize pipeline step, the router:navigation:success and router:navigation:complete events are fired with the /welcome instruction, no other events are raised in regards to the redirection/navigation to /login, but the redirection does happen (original example in PR https://github.com/aurelia/router/pull/97).
This causes issues when components subscribe to these events to change their appearance/behaviour, because the application ends up onto the /login page correctly, but the components receive the event telling them they are on the /welcome page.
This is what I see in the logs when I listen to the events and I log when the redirection happens in my authorize pipeline step:
processing /welcome
redirect /login
success /welcome
complete /welcome
I've tried the same logic but using canActivate in the welcome controller, which results in the same outcome above.
canActivate(params) {
return new Redirect("login");
}
In the events' data received (success and complete), the result is stating that the status of the navigation is completed, and the event instruction is /welcome, while the browser is showing /login.
From the event handler perspective, there is no way to determine or being notified what the actual final view is, in this case /login.
As a minor side note, for a cancelled event, result.status states cancelled, but the event name is spelled in American English: canceled.
I've found a workaround for the time being, which is to check router.currentInstruction directly from within the router:navigation:complete event handler (which contains the right navigation instruction), instead of using the instruction in the event data.
It happens because events are raised using the original instruction, but I agree it's not right. We should raise events using the instruction that actually created that result.
Thanks for the reminder about 'cancelled'. I'll make sure we're using the American English inflection consistently.
@bryanrsmith Can we close this now?
No, I need to make an adjustment to the instruction attached to the event. On Mon, Oct 26, 2015 at 8:03 AM Rob Eisenberg [email protected] wrote:
@bryanrsmith https://github.com/bryanrsmith Can we close this now?
— Reply to this email directly or view it on GitHub https://github.com/aurelia/router/issues/177#issuecomment-151166650.
Any progress on this issue? I have also hit the same wall
Had the same issue but using event.instruction.router.currentInstruction.config.name instead of event.instruction.config.name.
@powerbuoy +1 very useful.
Any news on this issue? It is a major issue with the router, and renders router events pretty useless now..
I wonder.. If it is still the same?
@Alexander-Taran It is: just ran into this specific problem.