Declarative C# UI a la Maui.Markup

[mischkl]

As a developer with previous experience using WPF, but who has in the intervening years used a variety of other UI frameworks, I was excited to hear about the CommunityToolkit/Maui.Markup project, which allows for declarative, C#-based UI definition, with minimal need for XAML.

As demonstrated by frameworks such as React, Flutter, Qt Quick, Jetpack Compose, SwiftUI and many others, I think there is plenty of demand for, or at least a broad developer base that is familiar with, using a programming language to declaratively define the UI. Meanwhile. some might see XML-based UI definition as outdated or clunky in comparison. I posit that offering a well-thought-out, well-supported, C#-based alternative to XAML could convince a wider range of developers to give WinUI a go.

I looked around to see if something like this is planned for WinUI 3, and found the project VincentH-Net/CSharpForMarkup, the previous version of which apparently formed the basis for Maui.Markup. To my eyes and mind, the UI code examples using that library are more compact and easier to read than the equivalent in XAML, not to mention needing only one language instead of two. For me, it seemed like my cognitive load was lightened and my comfort level increased. However, as mentioned here, the Windows Community Toolkit is currently not supported and additional work is needed to do so.

I would like to open up a discussion about the possibility of either assisting @VincentH-Net in his efforts to support WCT, or of adding/integrating this feature into the Windows Community Toolkit, similarly to what has been done with Maui.Markup.

Thanks for listening; I look forward to the discussion. 🙂

[VincentH-Net]

I'll be following this discussion with interest; I discussed this in a call with @nmetulev in December; maybe he can chime in?

The idea aligns with my general plans for C# Markup 2 as I shared them on Twitter a few weeks ago:

1. Fast-evolve C# Markup 2 as an independent OSS library
2. Contribute to MS-supported community toolkits (#dotNetMaui, #WindowsCommunityToolkit) and non-MS OSS products (#UnoPlatform, #AvaloniaUI)
3. Drive adoption and get MS to incorporate it from community toolkits into the products

If C# Markup support for the Windows Community Toolkit is realized, the effort will carry over to Uno Platform as well (@jeromelaban may have some thoughts about that)

PS C# Markup 2 leverages C# 10 features - which means .NET 6

[michael-hawker]

What would be required here of the Toolkit? Would it basically be a set of extensions specific to any Toolkit specific properties on our custom controls to allow for the declarative binding to the dependency property?

Should these not just be created automatically by Source Generators? There's a lot of stuff in the Toolkit, maintaining this by hand would seem infeasible. We have enough time trying to maintain the VS Designer Metadata for UWP... (which we also want to look at Source Generators for)

[francoistanguay]

For sure this has to be driven by Source Generators, the same way you'll want Source Generators for your own controls within the app you're building.

In order for C#-based markup to work, you need it for all of your dependencies, including Charting Controls, libraries of Behaviors and Components w/ attached properties...

[VincentH-Net]

C# Markup 2 uses code generation based on reflection. The code generation is both guided by a bit of manual code and complemented with a relatively small number of manual API's.

E.g. see the generated C# Markup code for all of WinUI 3. This file contains all generated code for 500+ WinUI 3 types.

[VincentH-Net]

@michael-hawker wrote:

What would be required here of the Toolkit? Would it basically be a set of extensions specific to any Toolkit specific properties on our custom controls to allow for the declarative binding to the dependency property?

Should these not just be created automatically by Source Generators? There's a lot of stuff in the Toolkit, maintaining this by hand would seem infeasible. We have enough time trying to maintain the VS Designer Metadata for UWP... (which we also want to look at Source Generators for)

For C# Markup to support the Toolkit, the only thing that is needed from the toolkit itself is that it exposes it's components in a public API that allows to create and configure them from C# (e.g. WinUI 3 does not expose some API's to C# that are used by the XAML engine - this is something to avoid). I expect that the toolkit already does this (unless a part of it is implemented in C++)

Note that C# Markup leverages C# 10, therefore .NET 6, therefore it can support WinUI 3 libraries but not UWP libraries.

C# Markup 2 for the Toolkit would be a separate NuGet that depends on the existing Toolkit NuGet(s); the main benefit of including the markup NuGet in the Toolkit is to lower the barrier of adoption.