Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parent navigation guard inconsistently re-run when redirecting between child routes #2224

Closed
pm0u opened this issue Apr 25, 2024 · 8 comments

Comments

@pm0u
Copy link

pm0u commented Apr 25, 2024

Reproduction

https://codesandbox.io/p/sandbox/vue-3-router-forked-ns47pv

Steps to reproduce the bug

On the homepage, click the link labeled "start the redirects (hard nav)"
Observe the console
After clicking this 3-4 times you will get the beforeEnter for home logged in-between a child redirect. eg

home beforeEnter
child1 beforeEnter
child2 beforeEnter
home beforeEnter
child3 beforeEnter
child4 beforeEnter

Expected behavior

Parent beforeEnter would only ever run once when changing between child routes. Eg logs matching

home beforeEnter
child1 beforeEnter
child2 beforeEnter
child3 beforeEnter
child4 beforeEnter

Actual behavior

Parent beforeEnter is re-run in an inconsistent/hard to predict manner.

Additional information

Initially found on vue-router v4.0.12 but was able to repro on latest per sandbox.

@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

Relevant docs explaining expected functionality: https://router.vuejs.org/guide/advanced/navigation-guards.html#Per-Route-Guard

@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

per the repro, seems to be isolated to when the redirect chain starts on initial "load". Notice it does not happen if the redirect chain is started from the router-link. Only the hard nav version

Copy link
Member

posva commented Apr 25, 2024

Since you are redirecting while entering on the first time, it has to trigger again each time you redirect. This is the correct behavior. After the first navigation to one of the children, it doesn’t re enter the parent so it doesn’t trigger again.

@posva posva closed this as not planned Won't fix, can't repro, duplicate, stale Apr 25, 2024
@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

how is this the correct behavior? we are not re-entering the parent. We are entering a separate child

@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

Also, it doesn't always happen on the first redirect. Sometimes it happens on the 2nd or third which would not be "while entering."

Additionally, sometimes it doesn't happen at all. It also doesn't happen when the redirects are preceded by a router navigation. Is this difference expected?

See below for clarifications on the weird behavior

@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

@posva

If that is the correct behavior, then this series of events shouldn't be possible, correct?

home beforeEnter
child1 beforeEnter
child2 beforeEnter
child3 beforeEnter
child4 beforeEnter

This is also reproducible randomly at the repro I shared.

@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

Seems to perhaps be an issue with the sandbox env. Opening in a new window, the logs I get are:

home beforeEnter
child1 beforeEnter
home beforeEnter
child2 beforeEnter
home beforeEnter
child3 beforeEnter
home beforeEnter
child4 beforeEnter

So, seems the inconsistency at least is due to the environment. But regardless, is this confirmed to be expected behavior that the parent nav guard would trigger before every single redirect?

If it is, then is it possible to accomplish a redirect from child to child without re-running the parent beforeEnter? If not, I think the docs should be updated as they seem to suggest that this would not be how the navigation guards would be handled.

image

@pm0u
Copy link
Author

pm0u commented Apr 25, 2024

Following a router link to any of the "redirected to" examples does not trigger the parent before enter so this is an inconsistency with the handling of a router-link vs a redirect when going between siblings. I think at least the docs should be updated to clarify how these situations are handled differently if this is in fact the desired behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants