Closed acoutts closed 4 years ago
Hello @acoutts, thanks for the ask!
The @NuRouter tag can be used when you want grouping routers, for example:
You have the AuthenticatedRouter with some route declarations and decided to create another router like the HomeScreenTabsRouter to separate some routes and be more organized. If you add the HomeScreenTabsRouter as a @NuRouter, you will use the same Nuvigator as AuthenticatedRouter like if you have just one router. With this, you will use just one stack of pages and just one Nuvigator. Considering that you don't need two different stacks of pages, having two Nuvigators will be less performatic then have only one.
The main idea for @NuRoute is to be used to declare the routes that your Nuvigator will handle in the same stack.
If you want to have different stacks of pages you can use the FlowRoute that knows how to handle multiple Nuvigators, which will give you more control of the stack, you can close an entire flow for example. In the FlowRoute you will need to add a Nuvigator in the tree, as you did in your example.
In conclusion, you shouldn't use the first example because the ScreenRoute doesn't know how to handle multiple Nuvigators and probably you will have problems when you try to pop ou push your pages.
If you still have doubts about it, please fill free to ask.
Thanks! In 0.3.0 I don't see any references to FlowRoute (but saw it in the documentation) - is there a beta version or other release where I can try that out?
Sorry about that, we have an open WIP PR improving the documentation. We still need to update to the version 0.3.0. But you can read to understand more about router composition and other stuff, the theory stills the same.
Got it working with the FlowRoute now, thanks for the tip on the documentation.
One more somewhat related question: how can I make the transition between routes instant and not use any animation, to mimic a tab bar navigation?
I tried this but with no luck- both screens show up for about 1s on top of each other:
class NoAnimationScreenType extends ScreenType {
const NoAnimationScreenType();
@override
Route<T> toRoute<T extends Object>(
WidgetBuilder builder, RouteSettings settings) {
return PageRouteBuilder(
pageBuilder: (BuildContext context, Animation<double> animation,
Animation<double> secondaryAnimation) {
return builder(context);
},
settings: settings,
transitionsBuilder: (_, Animation<double> animation,
Animation<double> second, Widget child) =>
child);
}
}
const noAnimationScreenType = NoAnimationScreenType();
Nevermind, that did work - I just had to make sure the screens had an opaque background.
How can I get the current route in the new nuvigator refactor? In the old one, this worked:
Nuvigator.of(context).currentState.stateTracker.stack.last.settings.name
But now it appears the currentState
member no longer exists.
I've thought I could use the navigation observer hook to keep track somewhere my current route, but I wasn't sure if there's a better way to do it now.
You can access the current Route by the context itself, no need to mess with the Nuvigator stack:
ModalRoute.of(context)
Should work.
However, the stateTracker should be available just, omit the currentState
: Nuvigator.of(context).stateTracker
Ah! Thanks alot @leoiacovini. You guys have quite the library here, I'm really looking forward to seeing it evolve. This is exactly what I was looking for migrating from React Native where I used this lib: https://reactnavigation.org/
@leoiacovini is there a way to access the current route from outside of build context? Before I was using my approach above but calling it from a global key to get at it from outside of build context.
When is it appropriate to use this format:
vs this?