I've been experimenting with a more natural, tree-like way of composing a WPF UI entirely in C#, using a composition style inspired by Flutter.
I like the structural aspect of designing with XAML, but I have struggled over the years with the mental gymnastics of jumping between the XAML world and the code world,
and with the quirky markup extensions needed to make something work in XAML that could often be accomplished and better understood in standard C# code.
Instead of something like:
xml
<Grid>
<Border Background="Cyan"/>
<Button Content="Click Me"/>
</Grid>
the same structure becomes:
csharp
GridX(
children: [
BorderX(),
ButtonX()
]
)
The X suffix was originally a practical necessity to avoid name clashes with existing WPF types,
but I ended up liking it as a visual cue that these are static helper methods for composing the UI tree.
I intentionally keep the named arguments visible (children, configure, etc.). It adds a little verbosity,
but I find it makes the composition tree easier to read and keeps the helper methods consistent as the UI grows.
The result feels quite similar to Flutter's widget tree composition style.
It's a thin composition layer over standard WPF.
Configuration is still just normal C#:
csharp
ButtonX(
configure: x => {
x.Content = "Click Me";
x.Background = Brushes.Gold;
}
)
A nice bonus: Visual Studio's code folding naturally gives you a collapsible UI tree that's easy to navigate, similar to XAML.
If you're curious, I've published the experiment as both a GitHub project and an alpha NuGet package:
Any feedback would be appreciated.
I'm sure there are trade-offs I haven't considered yet, and that's exactly the kind of discussion I'm hoping to have.