Refactor namespaces for extension types

[Sergio0694]

Related to #3422

PR Type

What kind of change does this PR introduce?

• Refactoring

What is the current behavior?

Quoting from #3422 (comment), 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?

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:

<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:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. 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
• New major technical changes in the toolkit have or will be added to the Wiki e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

[ghost]

Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

Went through about half and provided some initial feedback on a couple of items.

I like trying to see if we can do something with the SurfaceDial API (I have one somewhere I can try to test with if we change things). I'm not sure if SurfaceDial and SurfaceDialOptions are the best names, we haven't actually implemented this pattern yet for the Graph, but it's on our minds: CommunityToolkit/Graph-Controls#67

[michael-hawker]

FYI @Sergio0694, when you create the PR, you can set the base branch to the other branch you had created in the other PR, so that those commits won't show here against the main branch.

After that other PR is merged, we could rebase back off the main branch.

[michael-hawker]

Not sure if I didn't get to them yet, or if we didn't think about it... what about our Converters in the ...UI.Converters namespace? @Sergio0694 @mrlacey thoughts?

[michael-hawker]

@Sergio0694 looks like the build failed as unit tests weren't updated with the namespace changes for their usings or something?

[mrlacey]

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:

<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? 🙂

I do like the look of this shorter, simpler, grouped syntax.
Rather than a straight breaking change, could the new options syntax be added as a separate option and the old way marked as deprecated so there's a timeframe for developers to adjust and change existing code?

[mrlacey]

Not sure if I didn't get to them yet, or if we didn't think about it... what about our Converters in the ...UI.Converters namespace? @Sergio0694 @mrlacey thoughts?

I'm not sure what you're thinking about checking or changing here.
Everything seems to be consistently in the Microsoft.Toolkit.Uwp.UI.Converters namespace.

The only thing that could be related and sticks out to me is the Microsoft.Toolkit.Converters class. What's bad is that it's a generic name for a class with only one static method and the documentation says it contains a "[s]et of helpers." I'd be happy to discuss giving that a better name.

[Sergio0694]

I do like the look of this shorter, simpler, grouped syntax.
Rather than a straight breaking change, could the new options syntax be added as a separate option and the old way marked as deprecated so there's a timeframe for developers to adjust and change existing code?

@mrlacey I'm wondering whether it's actually worth it to have that considering the massive amounts of breaking changes we have in 7.0 anyway, from whole packages being split to general API changes with no intermediate obsolescence of earlier versions.
I mean, this entire PR is massively breaking per se already 😄
Wouldn't it be possible to just make all these breaking changes now at this point so that devs will only have to do these changes once when 7.0 lands, and then be set for future versions, instead of having to deal with multiple consecutive breaking updates?

[mrlacey]

@mrlacey I'm wondering whether it's actually worth it to have that considering the massive amounts of breaking changes we have in 7.0 anyway, from whole packages being split to general API changes with no intermediate obsolescence of earlier versions.
I mean, this entire PR is massively breaking per se already 😄
Wouldn't it be possible to just make all these breaking changes now at this point so that devs will only have to do these changes once when 7.0 lands, and then be set for future versions, instead of having to deal with multiple consecutive breaking updates?

Is there a (generated-hopefully) list of all the breaking changes so far?
I'm not clear the extent of the other breaking changes that have been made. Changing namespaces and having some packages split seems like something tooling can easily help with. Having to manually rewrite code in a different way without prior warning seems more of an imposition. I'm just wondering if there is already precedent here.

[michael-hawker]

@mrlacey yeah we've been trying to telegraph for a while that 7.0 is going to be a big release with breaking changes. The whole start of my release blog post is going to be calling that out that the release has cleaned and changed a lot of things.

We've been tagging PRs and should have our list of breaking changes. Hopefully for most folks it'll just be some namespace changes or including different packages, except for the couple of things we've removed (like ScrollHeader and the ImageEx caching).

So, I'm ok with us just making straight changes, as we have a bad habit of not cleaning up things later as well. I think the main exception to this is the DispatcherHelper where we know a ton of folks are using it and will need to migrate to DispatcherQueue for WinUI 3. Things like the SurfaceDial helpers are going to be a lot more niche in their usage.

[mrlacey]

Ok. I'm happy with a straight change if there's loads of other breaking changes too.

[Sergio0694]

Awesome 😄
@michael-hawker I can go ahead and make those changes once we all agree on the naming and on the new API surface, I guess we can either brainstorm that here or we can sync up at some point to briefly discuss those changes when you have some time 👍

[Sergio0694]

Note for reviewers: I'm aware there are conflicts to be solved, but I'm waiting for #3685 to be merged first to then rebase this PR on top of master directly. This branch is currently based on top of that PR as well, so I'm fine with waiting for that first before solving conflicts and making this PR to date to avoid creating even more conflicts between the three branches 😄