Xamarincommunitytoolkit: [Enhancement] Separate Controls from XamarinCommunityToolkit for keeping slim

[jingliancui]

Summary

As XamarinCommunityToolkit is growing, It will become bigger and bigger.
For keeping application package and the lib slim, may be we can separate the big lib to little libs like this nuget structure:

Xamrin.Forms (base)
--XamarinCommunityToolkit (second)
---MediaElement (third)
---TabView (third)
---... etc ((third))

[ahoefling]

As far as I understand the linker removes APIs that aren't used when you build your application in release mode. I know this is true for iOS and Android apps. I am not sure how the linker works in tizen, windows, linux, or macOS based apps. If APIs aren't removed on those platforms I can see real value in splitting things out as you suggested.

The Windows Community Toolkit uses this strategy and as a developer I find it confusing to manage which NuGets I have included in my project. This is especially frustrating when I am trying to use a feature of the toolkit that I have not referenced and my code isn't working. I understand this is an easy NuGet download, but if the linker is working as expected I don't see a need.

[jingliancui]

Got it, Almost forget linker feature.

[pictos]

@jingliancui This lib is linker safe, this means that if you use your Linker at assembly and SDK only level, the XCT will be linked. You can see the PR here #210

[jingliancui]

@pictos Great, make sense of it.

[jfversluis]

Thanks for the suggestion @jingliancui! Does the linker address your concerns?

I think for now we should be good. In the future I foresee certain controls needing maybe third-party dependencies. I think when that happens we should put that control in a separate library for that reason. As long as that is not the case, I think we can keep everything in one place as much as possible.

Another path would be to split the library into multiple ones by namespace I would reckon. So: behaviors, converters, etc. and not per control, then we would get an overload of different libraries while we are actually trying to unite some of these :)

Does that make sense?

[DennisWelu]

I think the linker goes a long way for keeping the end bits light and so less is better in general.

I was looking at the recently added Command implementations and my first thought was that anything that doesn't need to have a Xamarin.Forms dependency maybe should be split. So you have UI stuff and non-UI stuff. But then looking at what the rest of the toolkit contains it's all pretty tied to XF, including part of the Command implementation. So like the DependencyService that comes in the box with XF, you can choose to use that or bring your own. Same with the Command implementations here I suppose.

[DennisWelu]

Although I should add...the ObservableRangeCollection sure is a handy class and it is not tied to XF. Would be nice to have available in projects that don't have XF dependencies. If more and more of those types of utilities are created it adds merit to a split.

[ahoefling]

@DennisWelu I added ObservableCollection range manipulation APIs to the BCL but it was pulled before release .NET Core 3 because of problems with WPF downstream. I am hoping I can get it implemented for .NET 6.

[AndreiMisiukevich]

I guess this issue can be closed. For now, we decided to keep all stuff in the single NuGet package.
But feel free to raise this conversation again in the future again if you wish.