router icon indicating copy to clipboard operation
router copied to clipboard

Cancelling a navigation instruction with a redirect raises inconsistent navigation events

Open bfil opened this issue 10 years ago • 11 comments

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.

bfil avatar Aug 06 '15 15:08 bfil

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.

bfil avatar Aug 06 '15 19:08 bfil

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.

bryanrsmith avatar Aug 07 '15 21:08 bryanrsmith

Thanks for the reminder about 'cancelled'. I'll make sure we're using the American English inflection consistently.

bryanrsmith avatar Aug 07 '15 21:08 bryanrsmith

@bryanrsmith Can we close this now?

EisenbergEffect avatar Oct 26 '15 15:10 EisenbergEffect

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.

bryanrsmith avatar Oct 26 '15 15:10 bryanrsmith

Any progress on this issue? I have also hit the same wall

aozisik avatar Mar 21 '16 11:03 aozisik

Had the same issue but using event.instruction.router.currentInstruction.config.name instead of event.instruction.config.name.

powerbuoy avatar Aug 03 '16 10:08 powerbuoy

@powerbuoy +1 very useful.

danhowitt avatar Sep 02 '16 11:09 danhowitt

Any news on this issue? It is a major issue with the router, and renders router events pretty useless now..

pfurini avatar Oct 16 '16 07:10 pfurini

I wonder.. If it is still the same?

Alexander-Taran avatar Apr 03 '18 23:04 Alexander-Taran

@Alexander-Taran It is: just ran into this specific problem.

RomkeVdMeulen avatar Jun 22 '18 14:06 RomkeVdMeulen