-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Split up the controls package. #3594
Comments
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! |
I should mention my personal thoughts are that
|
@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'? |
The sample app already has groupings, but not everything listed above shows up in the sample app :/ |
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 |
@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 |
just |
Are there separate plans (& issues) for trying to remove the dependencies? If there are alternatives? |
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. |
@mrlacey good points. We also already have a
I was thinking probably we'd have names like
@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 |
I am putting together a list of their significant dependencies right now, it's clearer than my branches. |
See #3578 (comment) |
As "Layout" seems like a compelling category. I propose that these controls belong in the Ask if these controls belong in the And propose that these controls do not belong in the |
My thoughts, based on the assumption that Layout refers to "controls that affect or define the position of multiple other controls within the view."
|
Ideally, we deprecate It's on my backlog as a follow-on from #3122. |
We're close to removing the Animation package dependency, though Plan is to create 4 packages:
Thoughts on names? We may not split the middle-two to start and see how that works... |
Putting multiple things together and calling it standalone has a fun level of irony to it. |
For Though we still have the Win2D based behaviors in the Animations package to contend with how we want to deal with them... I think what we do is we create a base In either case, the Adding a TODO list here for my working branch for these steps:
Open Questions:
<SomeFrameworkElement...>
<extensions:CompositionEffects>
<effects:Blur ...>
</extensions:CompositionEffects>
<!-- AND/OR ? -->
<animations:Implicit.ShowAnimations>
<animations:TranslationAnimation Duration="0:0:1" From="0, -200, 0" To="0" />
<animations:OpacityAnimation Duration="0:0:1" From="0" To="1.0" />
<effects:BlurAnimation ..../>
</animations:Implicit.ShowAnimations>
</SomeFrameworkElement> (Or that work directly with the implicit animation helpers to do these effects? I think it'd be OK for the Win2D Media package to reference our newly made light-weight animations package for that...?) FYI @RosarioPulella @azchohfi @nmetulev for thoughts on this conundrum... |
For now I'm leaving the reference on the Animation package for Behaviors in case we decide to keep that reference as part of my discussion above. I have the new Animation and Behaviors packages building. I need to fix the Sample for |
That sounds rather nice. I like where this is going, it seems like it would be a great improvement if we can decouple some of these parts of the API and make them more flexible. I will start an investigation on composing |
Alright, I think we've laid out an initial plan. Now that #3633 is merged, and we know from #3634 that the @RosarioPulella I'll assign this to you to hold the baton on. As mentioned, just remove Let's start with 3 packages (a Styleless |
@RosarioPulella was thinking of doing a quick survey to get some insight on where we could split 'Standalone' vs. Non-Standalone controls as discussed here. (I've checked and we should be able to cobble something together quick in the Office Forms.) Thoughts on if we should try and ask about a different splitting line or anything though? Let me know your thoughts. |
@RosarioPulella thought a bit more and decided to take a look at the WinUI categories from their control gallery and try and condense them down:
We kind of use a similar split in our Sample App. Wondering if we could get a cleaner split of taking the rest of our stuff beyond Primitives and Media and segmenting it into 3: Input, Layout, and 'Chrome'? Not sure what to call the last one. It's almost like Adornments... but that means something else from WPF/XAML land. I'm also wondering if we just add to the existing Layout package if we plan to end-up with the WinUI dependency in the future anyway... Let me know any thoughts you have in the morning and we'll sync during the day to figure out a plan for the week. |
Interesting, so maybe the controls would split into the categories like this?
What about these other controls? |
Yeah, InAppNotification, Menu, and TextToolbar would be in 'Chrome' as well. Wonder if we just call that the 'Core' package and just pull out the Layout and Input items? @RosarioPulella thoughts? |
Well as far as categorization, its always easiest to have a "Un-catogrized" bucket. While Its would be hard to figure out whats in "Core" from the name I think its worth splitting the others controls out. Also if there was no "Other"-ish bucket then it would be a bigger barrier to entry for contributes. If contributors want to add a control and it does not fit in one of the established categories, they would have an easier time just adding it to "Core" than creating a new package. If a new control should be in a different or new package and they try to add to "Core" we can help them from there, rather then them having to deal with that thought process upfront and possibly on there own. |
Yeah, and part of this would be sorted out in an initial discussion/issue before we get to a PR. I think the last part is if we want to have two different 'Layout' packages or re-use the one we have. My only concern is that the current Layout package is pretty specific and small as there's no XAML bits... |
Yeah... And between 'Primitives' and the new 'Layout', The controls in 'Primitives' provides no interactions unlike some of the controls in 'Layout'. |
Something to think about... We now have a 'Primitives' package, but we had also put some helper bits in a 'Controls.Primitives' namespace (like the ColorPickerSlider)... How do we reconcile? Should our 'Primitives' package be a more aptly named 'Styleless' or do we change the namespace to be something else??? @windows-toolkit/toolkitteam thoughts? |
Well do we eventually want to put our controls in different namespaces for each package? |
### Related to #3594, working towards reducing footprint and increasing modularity <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> - Refactoring (no functional changes, no api changes) <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `Guard` and `ThrowHelper` APIs are part of the `Microsoft.Toolkit` package. This has a few downsides with respect to binary size for consuming package and overall API surface for consumers. The `Guard` and `ThrowHelper` APIs relied on a number of different NuGet packages that needed to be pulled in: - `System.Diagnostics.Contracts` - `System.ValueTuple` - `System.Memory` - `System.Runtime.CompilerServices.Unsafe` These packages are _only_ needed by those APIs, and yet with `Microsoft.Toolkit` being referenced by every other package in the whole Toolkit, every other package ended up having a dependency on those as well even when there was no use for them at all. This is not ideal both for final binary size, for the increased number of potentially unwanted APIs being imported by consumers, and due to the fact that many consumers want to minimize the number of NuGet dependencies in general. Furthermore, the `.Diagnostics` APIs can be very useful for all kinds of developers, especially those working in backend scenarios and with a particular focus on performance. It was not ideal to force those developers to also import APIs such as observable collections and other more UI-oriented APIs that were available in the base package (in fact I've spoken with a few devs that didn't like having to include anything other than just the `Guard` and `ThrowHelper` APIs when adding the package). For consumers on .NET 5 that don't use .NET Native, splitting the `Guard` and `ThrowHelper` APIs away means 80KB less in binary size (when not using IL trimming) when those APIs are not needed, which is effectively a 75% reduction on the base package. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> The `Guard` and `ThrowHelper` APIs have now been moved to a new `Microsoft.Toolkit.Diagnostics` package. Splitting this package completely removes all those dependencies from all other packages too 🚀 This work will also make it easier in the future to introduce a `.Diagnostics` source-only package, if we wanted to. **Note:** marking as breaking change due to the APIs being moved to a different package, but this PR doesn't do any changes to the overall API surface across the various packages - the APIs are still all exactly the same, just modularized differently. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes
@RosarioPulella they'll all stay in the I'm wondering if we just move the ColorPickerSlider to the main namespace but add the Browsable/EditorBrowsable component attributes to hide it from the editor? |
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"
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
Analysis
Related to #3145
The text was updated successfully, but these errors were encountered: