SwitchPresenter 2.0 and the new SwitchConverter 🦙❤️

[michael-hawker]

Fixes

Note this does not make an attempt at #516 for WinUI 3, that issue still needs resolution orthogonal to these changes. The specific new functionality works fine and has been tested on UWP, WinUI 3, and Uno Platform WASM.

PR Type

What kind of change does this PR introduce?

• New Feature

What is the current behavior?

ContentPresenter.Content is an object and can take general values/objects beyond just UIElements as it can use a ContentTemplate to transform that into UIElements.

This ability has been missing in SwitchPresenter as Case.Content was restricted to UIElement only.

We also have been able to use the same switch like power for transforming values within bindings/expressions.

What is the new behavior?

• Case.Content is now an object
  • This allows us to use SwitchPresenter.ContentTemplate and transform data in new ways within the confines of XAML
  • You can now use a SwitchPresenter to look at a value and return some new state/configuration/object instead which then seeds your UI DataTemplate, see new sample.
  • There's probably more ways this can be leveraged, yet to be discovered
• The core logic of SwitchPresenter has been abstracted to SwitchHelpers internal static class and generalized
  • This was done for code-reuse and simplification/separation of logic for the new SwitchConverter
  • The EvaluateCases extension is simpler and looks at the general cases to return the behavior vs. thinking about the end result
    • That is now handled by the parent
• Introducing SwitchConverter! This infuses the power of SwitchPresenter into a IValueConverter and allows you to easily transform possible values into resources, like brushes.
  • The new sample shows this where you can take an enum status value and get the corresponding brush easily from within XAML, before this would have had to be a custom converter with custom properties, now it can all be cleanly defined in XAML

PR Checklist

Please check if your PR fulfills the following requirements:

• Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
• Based off latest main branch of toolkit
• Tested code with current supported SDKs
• New component
  • Documentation has been added
  • Sample in sample app has been added
  • Analyzers are passing for documentation and samples
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• Tests for the changes have been added (if applicable)
• Header has been added to all new source files
• Contains NO breaking changes

Other information

Note: This couldn't have been done from Labs as SwitchConverter requires the change in the base Case.Content to object as well to function, so everything would have to be duplicated. Enabling new scenarios for SwitchPresenter and sharing the code makes the most sense here.

[Arlodotexe]

Generally, works and looks good. No major callouts, especially as it's an improvement to an existing component.

[michael-hawker]

Added a basic (but hopefully thorough) unit test based on the sample for Switch Presenter. Ran into some issues, so opened a tracking issue here: CommunityToolkit/Tooling-Windows-Submodule#227

Pushing what I have to check against the CI, ran this test fine locally though (at least on WASDK).

Want to add one for the SwitchConverter in the morning, then we should be gtg!

[michael-hawker]

TIL, apparently a similar SwitchConverter existed in WPF way back (seems like maybe in some other Blend-esque style library of the time):

• https://learn.microsoft.com/en-us/previous-versions/hh566315(v=vs.103)
• https://learn.microsoft.com/en-us/previous-versions/hh565363(v=vs.103)
• https://stackoverflow.com/questions/4366967/switch-select-statement-in-xaml-binding (looks like the blog mentioned was never indexed by wayback machine 😢)

I hadn't seen any of this before, especially when I created SwitchPresenter initially; at least they're all aligned together here now too for UWP/WinUI/Uno and sharing the logic/structure with each other. I think we've also done some improvements on the syntax/usage here and allowing for any type of input (at least from the SO version). We're also sharing the core logic now with the original SwitchPresenter we had which can be used in other scenarios, as we discovered here first in the Toolkit. Just more validation for this feature now from the past! 🙂

But SwitchConverter itself is apparently another WPF polyfill we can claim now technically! 😅 (Should probably follow-up later to add callouts in the docs and have a migration section.)