Should there be one navigation - NavigationView?

[pomianowski]

Discussed in https://github.com/orgs/lepoco/discussions/329

^{Originally posted by pomianowski August 4, 2022} Hey guys,
to make breaking changes as much as possible controlled I would like to ask if at this stage you think that there should be one navigation control - NavigationView.

Giving a bit of a wider perspective, when creating the current navigation, I did not follow WinUi but my own implementations created for the needs of other projects. While it made sense for a small scope of apps now I can see that there are too many use cases that I have not considered.

Control

NavigationView would have a presenter - Frame or some other presenting control and a Breadcrumb included. It should be a whole and not require additional controls. All this to keep everything as simple as possible.

For example:

<ui:NavigationView
  PaneStyle="Compact"
  PaneDisplayMode="Left"
  TransitionType="FadeInWithSlide"
  IsBackEnabled="True"
  IsBackButtonVisible="True"
  IsBreadcrumbVisible="True"
  MenuItems="{Binding}"
  FooterMenuItems="{Binding}"
  Navigated="OnNavigated">
  <ui:NavigationView.Header>
    <!-- Alternate way to create a breadcrumb? -->
  </ui:NavigationView.Header>
  <ui:NavigationView.Breadcrumb>  <!-- Accept object or FrameworkElement ? -->
    <ui:Breadcrumb
      FontSize="12" />
  </ui:NavigationView.Breadcrumb>
  <ui:NavigationView.Content>
    <!--
      Custom content rendered above the content of the page,
      may be breadcrumb or whatever else you like
      maybe dialog or snackbar? -->
  </ui:NavigationView.Content>
</ui:NavigationView>

NavigationView.PaneDisplayMode = PaneDisplayMode.Top; // Top / Left

NavigationView.SelectedItem; // Instead of the currently used property - Current

Parameters named similarly to Win Ui NavigationView - MenuItems instead of Items and FooterMenuItems instead of Footer.

Instead of NavigationStore or NavigationCompact class, we could use PaneStyle="Compact" - Compact / Store / Fluent.

Hamburger button

Hamburger button and Back button can be in title bar or the navigation itself. This is also a problem that should be solved. Should TitleBar implement a property like Navigation="{Bind RootNav}" or maybe a new NavigationControls control that could be placed in TitleBar.Header.

Frame

And the issue of rendering the control itself. We can skip the whole Frame control related stuff and simply use ContentPresenter or ScrollViewer. This will reduce the total number of rendered elements but the effect will be the same. Anyway, the most common way to create page objects is to do it before entering them in Frame.

I would be grateful for your suggestions and comments.

[MajorXAML]

Note that Microsoft has probably quietly redesigned NavigationView, forgetting to make changes to ToolKit...

I don't quite understand how they did it, as there are no significant changes in the file

[pomianowski]

At the moment, I'd like to at least get closer when it comes to functionality. The design itself can be improved at the later stage.

[LHTXQ]

It's good, but I just want as few changes as possible.

[MajorXAML]

@pomianowski Just want to note that in the new navigation there is no cache property https://github.com/lepoco/wpfui/issues/176

[pomianowski]

@MajorXAML I think that by default this should not be the concern of navigation, but a service provider. If someone wants to implement Cache, he can do it in his own PageProvider or ServiceProvider.

[MajorXAML]

@pomianowski Well yeah, it looks like it should be a property of the page https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.page.navigationcachemode?view=winrt-22621

[pomianowski]

The link you included implies a fairly complex mechanism integrated with the presentation controls and pages. The problem of managing instances when using a ServiceProvider lies with the ServiceProvider or PageProvider. If we don't use this model then Cache matters but at the moment, it can be considered as additional future to be realized sometime.

[MajorXAML]

Understandable.

Although many people prefer to pick up where they left off when switching pages 🙂

[pomianowski]

@MajorXAML, it doesn't take much effort. See Wpf.Ui.Demo.Mvvm. We are using singleton/scoped for the dashboard ViewModel, therefore the information about Counter remains as we switch between pages.