Proposal: Make NavigationView more friendly with data binding and implicit navigation

[huoyaoyuan]

Proposal: Make NavigationView more friendly with data binding and implicit navigation

Summary

Currently, the NavigationView control only manages the navigation menu, but not the actual content navigation. You suggested to use it as a replacement of Pivot, but it lacks the core feature.
The SettingItem property is also very unfriendly with binding.

Rationale

• User will want to just specify the relationship between menu items and contents, not bothering with the navigation code, which is usually just several common patterns.
• User will want to handle setting item like other items.

Scope

Capability	Priority
User can just specify type on each navigation element, and the navigation and back button will just work.	Must
User can also construct the content, instead of using type.	Must
The selected menu item get tracked when the frame is navigated by other action.	Should
When selecting setting item, the SelectedItem property don't necessarily the item container.	Should
The NavigationView gets a Frame without opt-in.	Won't

Important Notes

Make SettingItem settable can solve its issue and may harm little to consumers, but requires implementation change.
Allowing using navigation transition without Frame can help the manually constructed scenario.

Open Questions

The typed scenario is friendly with Frame and manually constructed scenario requires ContentPresenter. Can they introduce more complexity?

[omikhailov]

Actually, problem is Frame's API. NavigationView just has to consider these limitations and provide events for custom behaviors instead of some convenient APIs.

If Frame would use bindable Page property, or if it would expose commands instead of Navigate(), GoBack() and GoForward() methods, things would be much simplier.

As far as I understood, SettingItem is old property intended for compatibility with original UWP version of NavigationView, and now it normally should be placed in FooterMenuItems.

[huoyaoyuan]

As far as I understood, SettingItem is old property intended for compatibility with original UWP version of NavigationView, and now it normally should be placed in FooterMenuItems.

Agree. If the team also agree this, there should be documentation about SettingItem is unfriendly to binding and suggest not to use it.

[jaigak]

Well, NavigationView lets you use any content loader. It's not just for Frame so it shouldn't be that way. This flexibility allows you to use a WebView or FlipView for example. I have built a control that does something similar to what these issues want which also lets you specify content inline just like Pivot but Back navigation doesn't work with ContentPresenter so it needs to manually. Maybe WinUI could add a separate control that inherits from NavigationView and adds automatic navigation (no need to handle ItemInvoked/SelectionChanged and back button just works and you can just specify the content you want when you select a specific item.

[huoyaoyuan]

Well, NavigationView lets you use any content loader. It's not just for Frame so it shouldn't be that way.

Yes, then it's not convenient when I do want to use the most common patterns.

WinUI could add a separate control that inherits from NavigationView

This can be an alternate solution of this proposal. Anyway, this proposal means that there should be some control for this.

[StephenLPeters]

@anawishnoff and @YuliKl

[jaigak]

I've tried to do something similar in my own library. Basically, there's a custom class that inherits from WinUI NavigationView which handles ItemInvoked + SelectionChanged internally and based on the invoked item, it tries to navigate (there's also a custom class that inherits from NavigationViewItem which has a property to set the content to show when invoked). There are a few downsides to the approach:

• For items that it doesn't know how to navigate, there's no way to handle it manually.
• Since you specify the content in the property, it will be loaded in the visual tree even before it's needed.
• Extending the title bar with a custom title bar becomes harder as you don't have direct access to the internal ContentPresenter used by the control.