You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The current implementation of NavigationView works, but has a lot of issues. Everything started back in version 2.0.0 when I took a bad design decision: making each part of it separately. The NavigationView should work as a whole, with everything connected, which is impossible on the current implementation
Pages are not saved automatically. Even when using AutomaticKeepAliveClientMixin, sometimes the state of the pages get lost. (Keep pages State in NavigationView #760)
NavigationIndicator consumes too much memory and computing power. In the current implementation, it stores ALL the coordinates and sizes of the panes, which makes the app look heavy. It is also handled separately of PaneItem, which causes issues with animation (🐛 Weird animation in NavigationView #540).
Since the NavigationIndicator depends on the index of each item, which its info is stored in memory, it causes issues not only with memory, but with the handling of the position of the items. The indicator have to recalculate the data everytime the PaneItem changes, and can even lead to unexpected UI behavior (🐛 PaneItemExpander is expanding when adding a pane into NavigationView #876)
The transition between panes is done implicitly. This is easy to maintain, but it reduces our control over the animation, making it look not native.
Describe the solution you'd like
Pane Item
PaneItem is the most well-done implementation of the NavigationView, which means a lot of code can be reused. Yet, by making use of NotificationListener, it'd provide us a better handling of when the item is clicked. This implies that the current selected index should be done internally, which has several benefits: internal control of the indicator animation, ensure that the item is into view.
Indicator
NavigationIndicator should be rendered inside the PaneItem (#540 (comment)). This way, it'd not depend on the global coordinates system, therefore saving memory and computing power. This would also ensure that the indicator is positioned correctly every frame (by not being a pixel late). PaneItemExpander's children can also benefit from this.
Pane Transitions
Panes need to be handled together, specially the `open` and `compact` and `compact` and `minimal` modes. This ensures a smooth transition between them (#906)
Navigation Body
The view should store a local navigation history. This allow us to enable the back button by default, as well as knowing the previous selected index.
** Knowing the previous selected index is useful to display the sticky indicator animation in the correct direction. It can also be used by the body to transition the pages in the correct direction.
The body should not keep any page alive by default, but should enable developers to make use of AutomaticKeepAliveClientMixin to save the state of the pages.
Additional info
** I have considered making use of RenderBox, but I believe everything can be achieved using standard flutter widgets.
** Note that some APIs may change alongside this rework, which implies a new major version will be released with it.
Personal note
This proposal is huge and depends on a lot of factors to work. I usually don't have time to work actively on this project, but I still have a feeling for it. Please consider sponsoring the project so that I can spend more time on this.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The current implementation of
NavigationView
works, but has a lot of issues. Everything started back in version 2.0.0 when I took a bad design decision: making each part of it separately. TheNavigationView
should work as a whole, with everything connected, which is impossible on the current implementationAutomaticKeepAliveClientMixin
, sometimes the state of the pages get lost. (Keep pages State in NavigationView #760)NavigationIndicator
consumes too much memory and computing power. In the current implementation, it stores ALL the coordinates and sizes of the panes, which makes the app look heavy. It is also handled separately ofPaneItem
, which causes issues with animation (🐛 Weird animation in NavigationView #540).NavigationIndicator
depends on the index of each item, which its info is stored in memory, it causes issues not only with memory, but with the handling of the position of the items. The indicator have to recalculate the data everytime the PaneItem changes, and can even lead to unexpected UI behavior (🐛 PaneItemExpander is expanding when adding a pane into NavigationView #876)NavigationAppBar
is not flexible enough. The current implementation limits the dev into a set of design options that make the app look static (Allow overwriting the NavigationAppBar Layout #708)Describe the solution you'd like
Pane Item
PaneItem
is the most well-done implementation of theNavigationView
, which means a lot of code can be reused. Yet, by making use ofNotificationListener
, it'd provide us a better handling of when the item is clicked. This implies that the current selected index should be done internally, which has several benefits: internal control of the indicator animation, ensure that the item is into view.Indicator
NavigationIndicator
should be rendered inside thePaneItem
(#540 (comment)). This way, it'd not depend on the global coordinates system, therefore saving memory and computing power. This would also ensure that the indicator is positioned correctly every frame (by not being a pixel late).PaneItemExpander
's children can also benefit from this.Pane Transitions
Panes need to be handled together, specially the
`open` and `compact`
and`compact` and `minimal`
modes. This ensures a smooth transition between them (#906)Navigation Body
The view should store a local navigation history. This allow us to enable the back button by default, as well as knowing the previous selected index.
** Knowing the previous selected index is useful to display the sticky indicator animation in the correct direction. It can also be used by the body to transition the pages in the correct direction.
The body should not keep any page alive by default, but should enable developers to make use of
AutomaticKeepAliveClientMixin
to save the state of the pages.Additional info
** I have considered making use of
RenderBox
, but I believe everything can be achieved using standard flutter widgets.** Note that some APIs may change alongside this rework, which implies a new major version will be released with it.
Personal note
This proposal is huge and depends on a lot of factors to work. I usually don't have time to work actively on this project, but I still have a feeling for it. Please consider sponsoring the project so that I can spend more time on this.
The text was updated successfully, but these errors were encountered: