Unlike Navigator 1.0, which uses an imperative style of programming, Navigator 2.0 uses a declarative style.
And in the end:
final delegate = Get.find<ShoppingRouterDelegate>();
onPressed: () => delegate.push(CreateAccountPageConfig),
How is this declarative? It’s the same imperative API as we have in Navigator 1.0. Instead, you should have an app state, and you should change the state, not push routes imperatively. The UI should not have a link to RouterDelegate, it doesn’t feel right. The official example and corresponding design documents for Navigator 2.0 say it all.
If you look at the AppBar class you will see this comment:
“If there’s no [Drawer] and the parent [Navigator] can go back, the [AppBar]
will use a [BackButton] that calls [Navigator.maybePop].”
Wow, this is fantastic. I’ve been researching this but haven’t found a solution yet. This looks like the old code recreates the navigator key, right? This code came from the official Google Doc on Navigator 2.0. Just tested and it works
@kevindmoore
Yes! Every “get” call we create a new GlobalKey.
@override
GlobalKey get navigatorKey => GlobalKey();
Second part for new flutter users. I think it could be done something like this, if you want to override “get navigatorKey” from PopNavigatorRouterDelegateMixin like IDE suggests(in my case)
final GlobalKey _navigatorKey = GlobalKey(); @override
GlobalKey get navigatorKey => _navigatorKey;
Hi kevindmoore
In your demo, I see back button on browser is not synchronized, it is enable when I press back to Splash.
My step
Click Login
Click item 0
Click Add to cart
Click back button on browser
Click back button on browser → Splash will display button and back button on browser is still enable
Expect: back button on browser is disable.
Please help me for this case.
I didn’t notice what was changed in the updated version. The code samples still feel like there is a lot of “pushes” to the navigator, instead of modifying the state. For example, if we click on a deeplink, we parse its content, get the entity ID, then instead of pushing the new route with this information we just change the state. The router should receive a notification, that the entity details are available and update its routes correspondingly.
I think your approach is also valid, but I would prefer another approach when the widgets are not required to have a link to the router. Basically, we just need an intermediate layer between the widgets and the router. This layer is basically a state. I think this little change will make the router more declarative.
So, I haven’t changed anything yet. I’ve got a re-written app that works like this:
I have an AppState class that holds state for my app. It has items like logged in state and actions for going to other screens. The router listens for changes and reacts to those changes. I’ve totally removed the Get package and don’t share the router now. (Again, I haven’t updated the article yet)
@kevindmoore Could you update the code for the project? I couldn’t find many things that were mentioned in the article in the final version. For example there was no “setSplashFinished() method”