Code Quality: Converted SidebarView to a custom control

[0x5bfa]

Resolved / Related Issues

This is the first PR to improve the codebase of Sidebar controls in order to use this in the Settings pages and the Properties window.

• Code Quality: Broader SidebarView control usage #15283
  • Converted SidebarView to a custom control
  • Refactored accompanyying classes, such as sidebar automation peer classes

The last thing we have to do for SidebarView is to remove ViewModel DP from that and create some events instead.

Steps used to test these changes

I have tested and confirmed working well.

1. Open Files
2. Test tab stop: Move tab stop around the sidebar and see no issues/exceptions come up
3. Test the behavior:
   1. Double tap the sizer
   2. Move the sizer
   3. Shrink the height of the window to see if the ScrollViewer position and behavior is correct
   4. Click the Settings button placed at the footer.
4. See other things

CC: @marcelwgn

[marcelwgn]

PR looks mostly fine. A few notes:

1. Why are we switching to a templated control?
2. Naming and structuring wise, not sure I agree with moving events into a separate file and prefixing all template parts with "PART_".
3. If we rightfully rename the internal event handlers, we should match the control exactly (paneSizer vs PaneResizer...)

[0x5bfa]

1. That is because we are planning to use this control in other places like Settings NavView and Props window NavView. For example, originally SidebarView as a UC had a background brush that canno be overridden from outside, now it can be.
2. Tbh, I don't know what the PART_ means lol. I've seen in the WinUI repo and controls used in codebehind seem to be named like that. The reason why I separated event methods is simply for the sake of simplicitiy, I can merge it into SidebarView.cs
3. Of course, sounds like I have missed some of things, let me find and fix.

[marcelwgn]

Regarding 1, does lightweight styling not work for UserControls? I hope we dont aim to retemplate the entire sidebar for settings...

For the second, yes some WinUI controls use PART_ (which stands for template part, i.e. parts that should be included in the control) but working on the WinUI 2 repository, I can remember only one or two controls that did that. From what I remember most controls did not use that schema, not using that prefix was way more common.

[mdtauk]

PART_ Was a convention for controls back in the early Xaml controls, silverlight, and wpf.

Its for parts that the code relies on, and so when the control is re-templated it acts as a warning to include it in the template. It would give a warning in the designer if it was not present.

[0x5bfa]

Regarding 1, does lightweight styling not work for UserControls? I hope we dont aim to retemplate the entire sidebar for settings...

We will not do that absolutely, I'm trying to make it flexible for future use, largely taling about overring resources not the whole style, I don't think we use the same value as to the sidebar max threshold width and pane sizer position margin, etc:

Plus, we're planning to publish this control to the public thru NuGet (only if everything goes well), I was wanting to appropriately apply the setting from users of that control and they may want to re-style the whole default style (aside us):

<SidebarView Style="..." Background="...">
    ...
</SidebarView>

For the second, yes some WinUI controls use PART_ (which stands for template part, i.e. parts that should be included in the control) but working on the WinUI 2 repository, I can remember only one or two controls that did that. From what I remember most controls did not use that schema, not using that prefix was way more common.

PART_ Was a convention for controls back in the early Xaml controls, silverlight, and wpf.
Its for parts that the code relies on, and so when the control is re-templated it acts as a warning to include it in the template. It would give a warning in the designer if it was not present.

I see them across the WinUI 3 repo and even the newest controls (e.g. SelectorBar and TitleBar) have them. I'm convinced the reason why they add and I feel like we should use them. However, since this is a convention that is not documented in our coding guidelines, we may as well discuss whether or not later. CC @yaira2

[0x5bfa]

Theres an anooying issue that persists where i didnt touch. Let me close this and re-convert again...