Replies: 7 comments
-
I mean for GR to be the smallest, simplest thing to expose the capabilities of the Flutter Router API. Anything that can be done with standard Dart code in the existing framework of GR, I'd like to keep out. The fewer concepts the better. |
Beta Was this translation helpful? Give feedback.
-
The nice thing about this proposal imo was that that it did not add any complexity at all to the core Maybe this is something better implemented as a agnostic widget though. Presumably we could bind to the current location in flutter, without any reference to Edit - Ya it looks like this widget could bind to |
Beta Was this translation helpful? Give feedback.
-
I'd love a sample showing off such a thing to include with go_router. |
Beta Was this translation helpful? Give feedback.
-
Ended up putting this together and I think it turned out pretty cool: I think it should work with most Nav2 solutions, I built it on top of
Uses Nothing really specific to |
Beta Was this translation helpful? Give feedback.
-
I run into trouble running your package: gskinnerTeam/flutter-routed-widget-switcher#1 |
Beta Was this translation helpful? Give feedback.
-
Fixed that issue, and also added 3 other routing implementations :) Thx for the nudge to get it done! uynM4qBfGT.mp4 |
Beta Was this translation helpful? Give feedback.
-
very nice! |
Beta Was this translation helpful? Give feedback.
-
A common use case in desktop or web applications is to use a single persistent page, and then have views change their internal children, depending on the current location of the router.
For example, a
SideBar
component, may render theMainNav
child when on the home page, but then change it's child toDashboardNav
when the location changes to/dashboard/*
, and useSettingsMenu
when location is/settings/*
;This can be done imperatively now, like:
but it seems like we could make a nice little
AnimatedSwitcher
type Widget, that is automatically driven by an ancestor GoRouter.This could make it quite convenient to create little sub-trees around the app that are bound to current path.
The tricky thing here is that it really needs some sort of wild-card or partial-match ability to be very useful. If we have to define every set of specific matches, it will just be easier to use imperative code and logical branching.
Maybe a predicate style api could work? First match wins? Null matches anything.
@lulupointu any thoughts on the usefulness of this approach? We could basically use the
navigatorBuilder
to nest the main content area, and then sprinkle around the app other bindings to the location, that internally manage their own visual state as it relates to location.Beta Was this translation helpful? Give feedback.
All reactions