mirror of
https://github.com/CommunityToolkit/dotnet.git
synced 2026-10-27 10:36:38 +08:00
msftbot[bot]
2e99c2b445
## Related to #3422 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- 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 <!-- - 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. --> Quoting from https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3422#issuecomment-774484219, we have the current situation with respect to extension methods in the Toolkit: > On a related note - lately I've been thinking a bit about the various extensions in the toolkit in particular. @mrlacey already pointed this out in the first post in this issue, and I agree that that inconsistency is a bit weird, especially now that newer packages have started to just place them in their respective root namespaces. Basically we have the following situation: > > - `Microsoft.Toolkit.Extensions` (from `Microsoft.Toolkit`)❌ > - `Microsoft.Toolkit.Extensions` (from `Microsoft.Toolkit.Diagnostics`*) ❌ > - `Microsoft.Toolkit.HighPerformance.Extensions` ❌ > - `Microsoft.Toolkit.Mvvm.Messaging` ✅ > - `Microsoft.Toolkit.Uwp.Extensions` ❌ > - `Microsoft.Toolkit.Uwp.UI.Extensions` ❌ > - `Microsoft.Toolkit.Uwp.UI.Animations` ✅ > - `Microsoft.Toolkit.Uwp.UI.Media`** ✅ ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> This PR moves all the extensions (including XAML markup extensions) to the root namespace of each package. It also fixes some related issues like inconsistent naming, incorrect method locations, etc. ## Open questions Some extension types now have a number of properties that are only relevant when grouped together, as they refer a specific feature. For instance, all the SurfaceDial properties in `TextBoxExtensions`, or the ones related to Regex. @michael-hawker mentioned the "option" pattern that the Graph Controls have been using, which would look something like this: ```xml <TextBox> <ui:TextBoxExtentions.SurfaceDial> <ui:SurfaceDialOptions MinValue="0" MaxValue="10" EnableHapticFeedback="True" ... /> </ui:TextBoxExtensions.SurfaceDial> </TextBox> ``` Do we want to make this change as well while we're at it? Thoughts? 🙂 ## Additional details Haven't fully tested all the samples in the sample app just yet, have just focused on ensuring everything built fine for now. Also, this PR is based on top of #3685, which needs to be merged before this one. ## 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