[Feature] Split up the controls package.

[Rosuavio]

Describe the problem this feature would solve

There are many different kinds of controls in the controls package and there are many different levels of abstraction between the controls.

From a technical perspective, users have to pull in the whole package and all its dependencies (like Win2d and xmal.behaviors) just to get access to simple controls (like WrapPanel).

From a perspective of usability, having all our controls grouped together under "controls"

1. Makes the library as a whole less "understandable" as only a very general theme unifies it and consumers are not introduced to a specific domain.
2. Makes it harder to find our controls that do address specific domains in collections of packages. As in if a user is searching for a package to help with "layout" related tasks they most likely won't stumble across our package even though we have a substantial group of controls/panels that only address layout.

Describe the solution

Split the controls package.

We can either split things based on their "weight", splitting general/minimally dependent/simple controls from opinionated/heavily dependent/complex controls.

Or split the controls based on the domains or problem spaces they live in. Domains like "Layout", "Input" or maybe "Image capture/creation/examination/manipulation"

Whatever way seems like the best, I want to see the package split up into more focused categories.

Describe alternatives you've considered

1. Keep the package as it is.
2. Have a separate package per control.

Analysis

Control	For Layout	Standalone	Needs content	Provides Interactions	Styleless	Major Deps
AdaptiveGridView	x		x		x
DockPanel	x		x		x
StaggeredPanel	x		x		x
UniformGrid	x		x		x
WrapPanel	x		x		x
SwitchPresenter	x		x		x
LayoutTransformControl	x		x
HeaderedContentControl	x		x
HeaderedItemsControl	x		x
Carousel	x		x	x
MasterDetailsView	?		x	x
OrbitView	?		x	x		Animation #3627
BladeView	?		x	x
Expander	?		x	x
InAppNotification		?	x	x
RotatorTile		?	x
DropShadowPanel			x
ScrollHeader			x			Animation, Behaviors
TileControl		?	x			Animation #3633
TextToolbar			?	x
GridSplitter			?	x
ImageEx		x
Menu		x		x
Loading		x
RadialProgressBar		x
CameraPreview		x
ColorPicker		x		x
RadialGauge		x		x
RangeSelector		x		x		Animation #3611
RemoteDevicePicker		x		x
TokenizingTextBox		x		x
ImageCropper		x		x		Win2d
Eyedropper		x		x		Win2d
InfiniteCanvas		x		x		Win2d

Related to #3145

Hello, 'RosarioPulella! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Rosuavio]

I should mention my personal thoughts are that

1. We should group them based on domains.
2. We should at least split off a "Layout" package containing most of the controls that are labeled "For Layout" or "Needs content" as most of them are very lightweight and "layout" seems like a very important domain.

[michael-hawker]

@LanceMcCarthy pointed us to the Xamarin Forms breakdown here: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/controls/views

This has Expander as more of a 'Content' control/View vs. a Layout specifically.

Wonder if we want to be more fine-grained with 'Needs Content' to be a specific 'Content' vs. 'Items'?

[mrlacey]

The sample app already has groupings, but not everything listed above shows up in the sample app :/

[Rosuavio]

Other than the major categories, I'm curious what everyone thinks of having a separate "Panels" package separate from any "Layout" package, as they seem to distinguish themselves as not having any really visual appearance just a strategy for placing children.

Particularly I think AdaptiveGridView, DockPanel, StaggeredPanel, UniformGrid, WrapPanel would be our "Panels" (or whatever we want to name it). But something like the Carousel or the OribitView already has a strong visual style and in comparison to the "Panels" and is more opinionated/less general purpose.

[michael-hawker]

The sample app already has groupings, but not everything listed above shows up in the sample app :/

@mrlacey yeah our Sample App groupings are a bit 'fuzzy' too, so they may need to be restructured based on decisions here. But it could be an interesting thing to evaluate what we did in the past there with this matrix.

Curiously, besides SwitchPresenter was something else missing from the Sample App? (I need to create the sample for that control still it's new for 7.0.)

[mrlacey]

Curiously, besides SwitchPresenter was something else missing from the Sample App? (I need to create the sample for that control still it's new for 7.0.)

just SwitchPresenter

[mrlacey]

Are there separate plans (& issues) for trying to remove the dependencies? If there are alternatives?

[michael-hawker]

@mrlacey the only one I believe I filed so far is #3578 for the Animations package. I thought it was just RangeSelector and ScrollHeader, so that issue needs more details about what OrbitView and TileControl use.

[mrlacey]

Other than the major categories, I'm curious what everyone thinks of having a separate "Panels" package separate from any "Layout" package, as they seem to distinguish themselves as not having any really visual appearance just a strategy for placing children.

Particularly I think AdaptiveGridView, DockPanel, StaggeredPanel, UniformGrid, WrapPanel would be our "Panels" (or whatever we want to name it). But something like the Carousel or the OribitView already has a strong visual style and in comparison to the "Panels" and is more opinionated/less general purpose.

I would avoid this unless there is a good reason to have them in separate packages. While breaking into more packages makes each package smaller it also adds complexity to finding and selecting the right package.
As a consumer of the packages I wouldn't want to have to stop and work out (guess) whether I needed Controls.Layout or Controls.Panels. This could get particularly confusing if some controls ending Grid are in the Panels package and some another.
And what about DropShadowPanel? That is all about visual appearance.

[LanceMcCarthy]

I would avoid this unless there is a good reason to have them in separate packages. While breaking into more packages makes each package smaller it also adds complexity to finding and selecting the right package.

I agree with this. UWP has a linker and strips out unused stuff during release compilation with .NETNative. so it's not like having more dependencies is going to bloat your app.

This is more about developer and tooling experience, right? So, where is the balance between having a smaller dependency tree vs needing to search around for the right packages.

[michael-hawker]

@mrlacey good points. We also already have a Microsoft.Toolkit.Uwp.UI.Controls.Layout package as well that's explicitly related to WinUI ItemsRepeater.

Panels would be a tricky sell, especially with DropShadowPanel which isn't really a Panel...

I was thinking probably we'd have names like Base, Core, or Primitives, but those aren't that descriptive in helping find things. That's partly we still want the uber Controls` package which includes them all still to be there. That way knowing what's in each of these sub-packages is more of an advanced optimization step.

I agree with this. UWP has a linker and strips out unused stuff during release compilation with .NETNative. so it's not like having more dependencies is going to bloat your app.

This is more about developer and tooling experience, right? So, where is the balance between having a smaller dependency tree vs needing to search around for the right packages.

@LanceMcCarthy not all the things for XAML get stripped as the XAML metadata hold implicit references I believe; so those benefits aren't as apparent for the Controls package. @vgromfeld has been investigating this and can explain a bit more the technical details. Ref: #3145

[Rosuavio]

@mrlacey the only one I believe I filed so far is #3578 for the Animations package. I thought it was just RangeSelector and ScrollHeader, so that issue needs more details about what OrbitView and TileControl use.

I am putting together a list of their significant dependencies right now, it's clearer than my branches.

[Rosuavio]

See #3578 (comment)