-
-
Notifications
You must be signed in to change notification settings - Fork 463
[WIP] fix: fix guard with auto tab scaffold #1841
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
base: master
Are you sure you want to change the base?
Conversation
|
@Milad-Akarie Can you take a look on this please? |
|
@Milad-Akarie I think this should be a good feature to add. |
|
@Shreemanarjun its planned, it's more complicated than it seems |
|
@Milad-Akarie Are you going to work on this? |
|
Hi @Milad-Akarie , are you going to work on this? If not, please provide us more information about the context, and how it seems to be more complicated so that we can keep working on. Thanks in advance! |
|
Any updates on this? |
| final guards = <AutoRouteGuard>[ | ||
| if (_rootGuard != null) _rootGuard!, | ||
| ...route.guards, | ||
| ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main porblem with reusing existing guards, is that it might cause side effects. I tried to fix this in my fork and faced the same challenged.
Consider the following:
- you have a page and this page has three tabs
- these tabs are using the same guard used on the root router
- within the root you have a a custom guard that auto redirects to another page.
with the code you're proposing, if you open the page with that same tab, your expected behavior is tfor auto_route to simply prevent navigating to that tab where its guard has result.continueNavigation set to false. Instead, your code will also trigger the redirect, breaking the flow.
fix #1238 #1278