Declarative.NET
I AM ONLY PUBLISHING THIS PAGE FOR MY OWN PURPOSES AND TRACABILITY OF THIS PROJECT
IT WILL NOT BE DEVELOPED FURTHUR FOR THE FORSEABLE FUTURE
The idea, while interesting, doesn’t have much use
If I didn’t already have a thousand projects to work on, I’d do this
Origin
After playing around with MAUI while making PrepaCH, a though occured to me. MAUI had plenty of issues (some of which I have reported), so I wondered; what would a declarative app framework look like in C#?
I like the Flutter / Compose / SwiftUI approach, using a declarative system instead of imperative one. While design patterns are incredibly important, like State, many detailed or “child” patterns only seem to come around due to issues with the language or framework in question, like MVVM, or MVC, or MVP, or, or, or… Such design patterns feel like a solution to underlying problems with state management in imperative systems, and declarative systems address state management much better.
Of course, one cannot forget to mention Design Patterns: Elements of Reusable Object-Oriented Software when writing about design patterns.
Why not proceed
First off, Nobody Cares About Technical GitHub Projects. While this would be trying to fix some issues with MAUI, it wouldn’t really do much.
While only tangentially related, Slint seems interesting.
However, the main reason I’m also not continuing this project is because of the existing C# Markup in the Community Toolkit. While not declarative in the slightest, I feel like it’s not too far off and you could get there with Events.
Wouldn’t start from scratch
Of course, I thought of just starting from scratch. I looked into having the UI made in Skia / SkiaSharp. However, the mono project was recently ‘killed’, so who knows what the future of SkiaSharp would be. There is some documentation for Skai specifically in MAUI ](https://www.youtube.com/watch?v=ZwLNTBGh-Nw&ab_channel=InsidedotNET) [.
That being said, Skia only handles rendering, all other systems like input, canvas gestures, and all system-level calls like battery status, etc, would have to be redone from scratch. Going down that path would require a lot of groundwork before even getting to the declarative UI system.
As all that seems like too much work, it would make much more sense to use MAUI as a starting point. After all, the main point of Declarative.NET would only be to have declarative UI; there’s no point in reinventing the wheel when it can be avoided.
Implementation plan in MAUI
How existing frameworks work
First off, it’s important to understand the inner workings of existing declarative frameworks:
- How Compose works
- How Flutter works
- How SwiftUI works (my major gripe here is that Apple doesn’t have anything itself to describe how SwiftUI works…)
Rendering
An MVP would have the following:
- basic layout system with a view tree
- a few basic views through which all other widgets could be implemented: text, shape, image
The most important part to note here is how widgets / views are sized. In existing frameworks, views can size themselves only within their parent, they can’t become bigger than their parent or resize their parent.
The most basic implementation would be to directly use MAUI’s GraphicsView
The major benefit is that GraphicsView handles gestures, read more here.
However, as mentioned in the above section, Skia could actually be of help here to. Coincidentally, SkiaSharp can be used within MAUI. After all, Flutter started with Skia, so it would be a good starting point (they now use impeller which I think they develop).
The major downside here, compared to GraphicsView, is that the Skia views cannot handle inputs (afaik).
Code-wise
While that all nice and dandy, there’s some important things to consider with how this would be concretely implemented. C#’s Attribute system is a good place to start:
Source generators may be neat as well, but seem over complicated.
Events would play a central role in this, and I feel that Delegates would make a useful entry.
And that’s about it
Last words
I like the idea conceptually, but honestly I don’t have the time or energy to work on it.