Code Quality: Implement SidebarView2

[0x5bfa]

Description

The current sidebar implementation has several issues, which is simply because we ported the controls over to custom controls and was fairly a hard work.

1. The whole instance of ViewModel is passed to the control
2. The control uses Binding-s in the styles, which is AOT-incompatible
3. There's a dedicated view model for the user control, SidebarView with 1.3k loc
4. There's an interface for the view model
5. There's an interface for data template of the SidebarItem
6. Item clicking event is heavily tied to the view model
7. Item changed event is heavily tied to the related services like QuickAccessService

Here's the proposed version of the sidebar.

1. The control implementation design will be similar to that of NavigationView
2. The SidebarViewModel will be removed
3. Bindings will be done in MainPageViewModel
4. The control will make use of events for dragging and clicking
5. The view model will make use of events for data source from e.g. QuickAccessService
6. The control will allow to expand folders toward the tree view proposal

Here's the API spec:

• SidebarView2
  • prop: SidebarViewDisplayMode2 DisplayMode
  • prop: bool IsPaneOpen
  • prop: object MenuItemsSource
  • prop: object FooterItemsSource
  • prop: double OpenPaneLength
  • prop: object SelectedItem
• SidebarView2SectionItem
  • prop: object Icon
  • prop: object Text
  • prop: IList<object> Items
• SidebarView2Item
  • prop: bool CanDrag = true
  • prop: bool AllowDrop = true
  • prop: object Icon
  • prop: object Text
  • prop: bool IsExpanded
  • prop: bool CanExpand
  • prop: object Decorator
  • prop: IList<object> Items

Here's an example of usage:

<controls:SidebarView2
    DisplayMode="{x:Bind ViewModel.SidebarView2DisplayMode, Mode=TwoWay}"
    IsPaneOpen="{x:Bind ViewModel.SidebarView2IsPaneOpen, Mode=TwoWay}"
    MenuItemsSource="{x:Bind ViewModel.SidebarView2SectionItems, Mode=OneWay}"
    FooterItemsSource="{x:Bind ViewModel.SidebarView2FooterItems, Mode=OneWay}"
    OpenPaneLength="{x:Bind ViewModel.SidebarView2OpenPaneLength, Mode=OneWay}"
    SelectedItem="{x:Bind ViewModel.SidebarView2SelectedItem, Mode=TwoWay}"
    ItemClicked="SidebarView2_ItemClicked"
    RightClicked="SidebarView2_ItemClicked"
    ItemReordered="SidebarView2_ItemReordered">

    <controls:SidebarView2.EmptyView>
        <!-- empty view -->
    </controls:SidebarView2.EmptyView>

    <controls:SidebarView2.Header>
        <!-- inner navigation toolbar -->
    </controls:SidebarView2.Header>

    <controls:SidebarView2.Content>
        <!-- content + info pane + shelf pane -->
    </controls:SidebarView2.Content>

    <controls:SidebarView2.Footer>
        <!-- status bar -->
    </controls:SidebarView2.Footer>

</controls:SidebarView2>

Concerned code

The whole sidebar-related code

Gains

• Simplicity of the control implementation
• Isolation of the control and the backend (view model)

Requirements

• Implement a whole control, SidebarView2
• No code change in the application until we replace with this
• All work will be done in the playground app

Comments

CC @marcelwgn

[mdtauk]

Is this your attempt at making the Sidebar into a control that can be added to a Settings tab/page, as well as the properties dialog window?

[0x5bfa]

Is this your attempt at making the Sidebar into a control that can be added to a Settings tab/page, as well as the properties dialog window?

Yes. The current codebase is heavily hardcoded, and I cannot make refactoring plans because of its complexity unfortunately.

[marcelwgn]

Having built the control, I am obviously biased but I feel like this proposal is mixing two issues:

1. Complexity of the SidebarViewModel (badely named in hindsight)
2. Issues with the pure control

I do get that you seem to dislike passing an object to SidebarControl and sure, we can change that. But then you just move the problem somewhere else where you do countless binding of those functions from your control to the viewmodel in a different place. The reason it takes in an ISideBarViewModel is that it makes it clear what needs to be implemented for this control to easily work. We can also make it a bunch of properties but it certainly wont change how big the code will be to set all of that up (i.e. all that is in SideBarViewModel). And if you include those things in the API spec, I think it would argue the control would also seem more complicated than it does in the current proposal.

Also does your proposal include being able to reorder sections?

Not being AOT compatible is an issue, no idea why we didnt go with x:Bind from the beginning.

[0x5bfa]

We have agreed to remove the interfaces (phase 1) and the view model (phase 2).

https://discord.com/channels/725513575971684472/1450773530001018912

I'll merge this convo into #15283