Using .NET MAUI with fluent API, with Hot Reload, without the need for XAML - feedback requested

[idexus]

--- new edit

I understand the reasons for the rejection of the PR. I also understand that more convincing reasons are needed. So earlier, I started an issue about adding a few things to the maui library to simplify non-XAML development (I don't understand why it was moved to the Community Toolkit). I don't mean methods exactly, because that can be handled with extension methods. However, there are things you can't do and be 100% compatible with maui classes like:

• adding IEnumerable and IList interfaces for classes with [ContentProperty] attribute
• creating additional constructors
• providing hot reload for creating interface in code

Interestingly, it doesn't build maui project inconsistency and if implemented inside maui project you wouldn't need to unseal the classes. The design will improve in my opinion, and the performance will not spoil. @hartez @PureWeen @davidortinau @mattleibow

Hot Reload example

--- old

I have created a fork to build a fluent API support directly in the MAUI project (without wrapping and without subclassing). I ported my lib with some minor changes to the MAUI and it works.

https://github.com/idexus/maui/.../info.md

I need your feedback!

--- old

I have created a small wrapper library to use .NET MAUI in a declarative way, without the need for XAML. It is mostly auto-generated.

https://github.com/idexus/Sharp.UI

Usage example

new ScrollView
{
    new VerticalStackLayout
    {
        new Image("dotnet_bot.png")
            .HeightRequest(200)
            .HorizontalOptions(LayoutOptions.Center),
    
        new Label("Hello, World!", out var label)
            .FontSize(32)
            .HorizontalOptions(LayoutOptions.Center),
    
        new Label("Welcome to .NET Multi-platform App UI")
            .FontSize(18)
            .HorizontalOptions(LayoutOptions.Center),
    
        new Button("Click me")
            .HorizontalOptions(LayoutOptions.Center)
            .OnClicked(button =>
            {
                count++;
                button.Text = $"Clicked {count} ";
                button.Text += count == 1 ? "time" : "times";
            })
    }
    .Spacing(25)
    .Padding(new Thickness(30, 0))
    .VerticalOptions(LayoutOptions.Center) 
}

but unfortunately some classes are sealed so I have to make a wrapper for them.

e.g.:

PathGeometry, PathFigure, TapGestureRecognizer, PinchGestureRecognizer, PointerGestureRecognizer, SwipeGestureRecognizer, Ellipse, Polyline, Line, Path, Polygon, Rectangle, RoundRectangle, TableSection, ColumnDefinition, RowDefinition Style, Trigger,... etc.

If I want to create interface with these classes in a declarative way, I cannot do it without wrapping them.

My goal was:

new Path
{
    new GeometryGroup
    {
        new PathGeometry
        {
            new PathFigure(15, 50)
            {
                new LineSegment(800,150),
                new LineSegment(500,50)
            }
        },

        new EllipseGeometry()
            .Center(new Point(50,70))
            .RadiusX(10)
            .RadiusY(50),
    }
}
.Stroke(Colors.Yellow)
.Fill(Colors.Red),

Is there an option to unseal maui classes? It will make easier to create truly declarative way of creating interface, only in code.

Or my second question, can the Fluent API be implemented directly in the MAUI project?

[wubalubadubdub55]

That's a very neat idea. Have you tried talking to @davidortinau or @PureWeen?

[idexus]

I'll try, thanks

[saint4eva]

@Clancey James Clancey is already doing so. etching similar with Comet - C# MVU. And @jsuarezruiz is also doing something great with AlohaKit

[Xyncgas]

I never want to see any XAML it's too many noise fluent api is good, I can make UI entirely in C#, or even F# (a .NET language that can write less code than c#)

[YiannisBourkelis]

@idexus I would also prefer to construct the UI in a declarative way and your suggestion is very good. The problem is that now, for any change in the UI code we will have to rebuild the project to see the changes. Currently XAML hot reload is broken in MAUI. Sometimes it works, sometimes not. And there is no support for code hot reload.

[idexus]

@YiannisBourkelis @saint4eva @brminnick

I've created an alpha version of my library with hot reload. It uses Visual Studio Code and Reloadify3000 library.

Test Project:

https://github.com/idexus/HotReloadTest

[akhanalcs]

That was super cool! Great job!

If only we could find a way to get rid of those new, it'd look so clean.
I hope you contribute it to MAUI core. 🙂
First class support for UI in code would be amazing!

Also try talking about it to @davidortinau and @PureWeen. I'm sure they'll like it.

[saint4eva]

That was super cool! Great job!

If only we could find a way to get rid of those new, it'd look so clean. I hope you contribute it to MAUI core. 🙂 First class support for UI in code would be amazing!

Also try talking about it to @davidortinau and @PureWeen. I'm sure they'll like it.

The only thing he needs with the Maui core is for the team to unseal the sealed classes.

[saint4eva]

@YiannisBourkelis @saint4eva @brminnick

I've created an alpha version of my library with hot reload. It uses Visual Studio Code and Reloadify3000 library.

Test Project:

https://github.com/idexus/HotReloadTest

This is amazing. I will play with it and will give you some feedback. Do you have a CLI template to bootsrap the application e.g. dotnet new sharpui - something like this.

[Xyncgas]

Speaking of hot reload, I don't think it's that essential a feature, personally I have been coding Xamarin and MAUI and other UI framework for a while I just imagine what I am making, it's all in my head, and I use F# to write the UI and use MAUI to render the UI, so I just compile F# instead of running the app see if anything is wrong and it's very fast, or I can rely entirely on intelli-sense.

UI code doesn't have a lot bug if you know what you are doing, if you've made a lot of UI then you are going to get good and start doing the same thing everyday or even abstract stuffs to a higher level, then you can kinda hot reload faster than the computer because your mind is connected to the ideas of things just like we are connected to our great country as American

[idexus]

@YiannisBourkelis I know there is no support for code hot reload, but personally for me, creating a UI in code only, using a declarative way, gives more value than the XAML approach.

e.g. creating custom content views where all bindable properties are generated automatically form the interface declaration, and grid definitions and data bindings are created inline is far more readable in code then in XAML.

example from my lib:

[BindableProperties]
public interface ICardViewProperties
{
    string CardTitle { get; set; }
    string CardDescription { get; set; }
    Color CardColor { get; set; }
    Color BorderColor { get; set; }
    Style DescriptionStyle { get; set; }
    View ContentView { get; set; }    
    string ButtonTitle { get; set; }
}

[SharpObject]
public partial class CardView : ContentView, ICardViewProperties
{
    public event EventHandler Clicked;

    public CardView()
    {
        this.BindingContext = this;
        Content = new Border
        {            
            new Grid
            {
                new VStack
                {
                    new Label()
                        .Text(e => e.Path(nameof(CardTitle)))
                        .FontSize(25)
                        .TextColor(Colors.White),

                    new Label()
                        .Text(e => e.Path(nameof(CardDescription)))
                        .Style(e => e.Path(nameof(DescriptionStyle))),
                },

                new ContentView()
                    .Row(1)
                    .Content(e => e.Path(nameof(ContentView)))
                    .HorizontalOptions(LayoutOptions.Center)
                    .VerticalOptions(LayoutOptions.Center)
                    .SizeRequest(120,120),

                new Button()
                    .Row(2)                    
                    .Text(e => e.Path(nameof(ButtonTitle)))
                    .BackgroundColor(AppColors.Gray600)
                    .TextColor(AppColors.Gray100)
                    .OnClicked((sender, e) => Clicked(sender,e))
            }
            .RowDefinitions(e => e.Star(1).Star(2).Star(0.7))
            .RowSpacing(10)
        }
        .StrokeShape(new RoundRectangle().CornerRadius(10))
        .Stroke(e => e.Path(nameof(BorderColor)))
        .BackgroundColor(e => e.Path(nameof(CardColor)))
        .SizeRequest(200, 300)
        .Margin(50)
        .Padding(20);
    }
}

than you can use this in that way:

new VStack
{
    new Slider(1, 100, out var slider),

    new CardView(out cardView)
        .CardTitle(e => e.Path("Value").Source(slider).StringFormat("Value {0:F1}"))
        .ButtonTitle("Play")
        .CardDescription("Do you like it")
        .CardColor(Colors.Blue)
        .BorderColor(Colors.Red)
        .ContentView(new Image("dotnet_bot.png").Aspect(Aspect.AspectFit))
        .OnClicked(e =>
        {
            e.CardDescription = "Let's play :)";
        })
}

[VladislavAntonyuk]

You can use CommunityToolkit Maui Markup library: https://github.com/CommunityToolkit/Maui.Markup

[saint4eva]

Maui Markup is MVVM oriented.

[saint4eva]

That's impressive! Would you mind contributing your idea directly to CommunityToolkit/Maui.Markup? That way, I believe, your idea reaches out to the wider community and prevents fragmentation in libraries.

Options are good. Having different solutions or possibilities are good. some will be mvvm oriented. while some will be MVU inspired with fluent API.

[danielftz]

I think making Eventhandler fluent is an interesting idea that should be adapted in Community toolkit markup. However I don't think ALL properties is better declared in a fluent way. For example, adding Children to a Grid before defining the Row and Column definitions of a Grid isn't very intuitive to me

[danielftz]

The teams are very already small, splitting up the effort might not be a good idea

[idexus]

@danielftz The options are good though. In my opinion, the best solution would be a full implementation of the fluent API in the MAUI project. What I am talking about does not limit the possibility of declaring the interface as it is in the CommunityToolkit/Markup, it only gives an additional possibility to describe the interface in an intuitive way using curly braces. Unfortunately, to do this fully and well, you have to implement it directly in the MAUI using source generators, rather than doing it manually, method by method. It is to be done. It also does not restrict the use of XAML in any way.

[saint4eva]

Have you tried Comet? or AlohaKit?

[idexus]

I did not know. As you said, having different possibilities is good. I want to create a library that does not differ from the MVVM model, but allows defining the interface using the fluent API in an intuitive way, while allowing the existing MAUI code to coexist.

[idexus]

What I did in my library is also possible to be adapted directly in the maui project at a low cost, using source code generators. And I think it would make it much easier to create an interface without the need for XAML, without disabling the possibility of using it.

[saint4eva]

Fantastic. I will give your library a try 👍🏽

[JohnHDev]

Code over XAML is also my preferred approach, so I wrote a code generator that creates almost all of what I need automatically.
Ive then gone further and generated extension methods for bindings including support for property converters:

        _grid.AddChild(new Label().Row(row).Column(column)
            .Margin(2, 0)
            .TextBinding(nameof(ITestModel.Title))
            .TextColorBinding(nameof(ITestModel.StartDate), (DateTime d) =>
            {
                if (date == DateTime.Now.Date)
                    return Colors.Red;

                if (date.Year == d.Year && date.Month == d.Month)
                    return Colors.Blue;

                return Colors.Black;
            })
            );

Ive also implemented multi binding with converter support:

            .BackgroundColorBinding(new[]
            {
                new Binding().Path(nameof(ITestModel.TextColor)),
                new Binding().Path(nameof(ConfigModel.DarkMode)).Source(ConfigModel.Instance),
                new Binding().Path(nameof(ConfigModel.Opacity)).Source(ConfigModel.Instance),
            },
            (RGBA r, bool darkMode, int opacity) => r?.WithAlpha((100f - opacity) / 100f, darkMode ? RGBA.DarkGray : RGBA.White).ToColor())
            ;

This approach does not require any subclassing though.

[idexus]

As I mentioned earlier some classes are sealed, e.g. Path, so to implement IEnumerable interface I had to wrap them.

[JohnHDev]

I use extension methods for that very purpose:

        public static T AddChild<T>(this T d, View view) where T : Layout => d.With(() => { d.Children.Add(view); });

With this syntax:

new StackLayout()
    .AddChild(new Label().Text("bla"))
    .AddChild(new Label().Text("etc"))
    .AddChild(new ScrollView()
        .Content(new Label().Text("foo"))
        )
    ;

ScrollView has a Content property, so I have an extension method for Content which returns T etc.

        public static T Content<T>(this T d, View content) where T : ScrollView => d.With(() => d.Content = content);

[idexus]

Ok, it can be done like this, but personally I prefer to write it like this:

new StackLayout
{
  new Label("bla"),
  new Label("etc"),
  new ScrollView
  {
    new Label("foo")
  }
}

I think it is more readable.

for this purpose I subclassed ScrollView in this way

public partial class ScrollView : Microsoft.Maui.Controls.ScrollView, Sharp.UI.IScrollView, IMauiWrapper, IEnumerable
{
    ...

    public void Add(Microsoft.Maui.Controls.View content) => this.Content = content;

    ...
    ...
}

[JohnHDev]

Whatever works best for you. :)

I personally prefer the extension method approach, very readable, no subclasses, fully declarative, no XAML. :)

[idexus]

For fluent API, I also use the extended methods approach. For this, I agree that there is no need to create subclasses. I only need subclassing to create custom constructors and implement IEnumarable or IList interfaces.

By the way, MAUI without XAML is better ;)

[idexus]

I created a fork to build a fluent API support directly in the MAUI project (without wrapping and without subclassing)

https://github.com/idexus/maui

[idexus]

Some things can't be done without getting inside the maui project. Another solution is subclassing, unfortunately some maui classes are sealed, so you can't do it without a wrapper. That's why I asked to unseal them.

[idexus]

@mphill

Think about the work needed to alternative colors on a rows:

XAML: https://xamarinhowto.com/xamarin-forms-collectionview-alternating-row-colors/

vs

in my Sharp.UI you can do this like this:

public class AlternateCollectionPage : ContentPage
{
    class AlternateRowModel
    {
        public int Id { get; set; }
        public object DataModel { get; set; }
        public Style LabelStyle => new Style<Label> { Label.TextColorProperty.Set(Id % 2 == 0 ? Colors.DarkSlateGray : Colors.LightGray) };
        public Style GridStyle => new Style<Grid> { Grid.BackgroundProperty.Set(Id % 2 == 0 ? Colors.LightGray : Colors.DarkSlateGray) };
    }

    public AlternateCollectionPage()
    {          
        var itemSource = DataModel.SimpleData
            .Select((e, i) => new AlternateRowModel { DataModel = e, Id = i });

        Content = new VStack
        {
            new CollectionView
            {
                () => new Grid()
                {
                    new Label()
                        .Text(e => e.Path("DataModel.Name"))
                        .Style(e => e.Path("LabelStyle"))

                }
                .Style(e => e.Path("GridStyle"))
            }
            .ItemsSource(itemSource)
        };
    }
}

I think this is an easier solution than the XAML version after all.

[danielftz]

I agree that XAML sucks, but I think Community Toolkit Markup does the trick for me already, using fluent MultiBinding

private List<int> _nubmers = new List<int> {0,1,2,3,4,5,6,7,8,9};
public List<int> Numbers => _nubmers;



// in the constructor of some view
//...


new CollectionView
{
      ItemTemplate = new DataTemplate(()=>
      {
             new Label
             {
             }.Bind(Label.BackgroundColorProperty, 
                     new Binding("."),
                     new Binding(nameof(Numbers), source: this),
                     convert: ((int element, List<int> list )v)=>
                    {
                            if (v.list.IndexOf(v.element)%2 == 0)
                           {
                                     return Colors.Black;
                            }
                            return Colors.White;
                   }
                 
             }
      })
}
.Bind(CollectionView.ItemsSourceProperty, nameof(Numbers), source: this)

To me, I really like some of the syntax of Sharp.UI, like .Style(e => e.Path("GridStyle")), however overall I personally think it's not a significant enough improvement for me to warrant reworking core MAUI

[idexus]

ok, you can also do it with a converter

private List<int> _numbers = new List<int> { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
public List<int> Numbers => _numbers;

...

new CollectionView
{
    () => new Label()
            .Text(e => e.Path("."))
            .BackgroundColor(e => e
                .Path(".")
                .Convert((int n) => n%2 == 0 ? Colors.White : Colors.Black)
            )
}
.ItemsSource(Numbers)

As for the rework of the MAUI core, these are cosmetic changes that can be done with a source generator, such as implementing the IList and IEnumerable interfaces with Add() methods for [ContentProperty] attributes and adding a few additional constructors. It doesn't break the base. All the rest can go outside the MAUI core in the form of extensions, e.g. .Style(e => e.Path("GridStyle")). I can help with that, but they have to want to do it, and life will be easier for many.

Of course, all fluent extension methods can go into the Community Markup, they can also be auto-generated, for all classes.

[danielftz]

I like the way it looks. As far as I know Community Toolkit Markup already uses source code generation for some of it, so I think your contribution would be valuable there. @brminnick

[TheCodeTraveler]

Hi Everyone! There seems to be 2 main topics here:

• Create new Constructors for .NET MAUI controls
  • Edit: This is not possible until partial classes support external assemblies
• Create Extension methods for every missing .NET MAUI Property

First, thank you so much for this Discussion! I'm very excited to see this added to CommunityToolkit.Maui.Markup. If you haven't yet heard of the .NET MAUI Community Toolkits, it is a Community-driven, Microsoft-supported, library that we use as a staging ground for new features, contributed by the community, that will eventually be promoted into .NET MAUI.

For more information, here's a blog post I wrote when we released the .NET MAUI Community Toolkits: https://devblogs.microsoft.com/dotnet/introducing-the-net-maui-community-toolkit-preview/

Let's pave a path forward here for anyone from the community who would help with this effort!

## Overloaded Constructors

Edit: This is not possible until partial classes support external assemblies

Most .NET MAUI Controls are already using a partial class.

This means that we can create a second partial class, eg partial class Button that has a constructor accepting every Property as a default parameter.

### Implementation

Edit: This is not possible until partial classes support external assemblies

• Create a partial classes for each .NET MAUI Control
• Create a new Constructor that accepts every Property as a default parameter
• Assign the Properties from their appropriate parameters in the constructor

### Example

Edit: This is not possible until partial classes support external assemblies

namespace Microsoft.Maui.Controls;

public partial class Button
{
  public Button(Thickness padding = default, 
                  LineBreakMode lineBreakMode = default,
                  Thickness margin = default
                  // continue adding a parameter for every Property of `Button`, including the properties inherited by `View`
                  )
  {
    this.Padding = padding;
    this.LineBreakMode = lineBreakMode;
    this.Margin = margin;
    // continuing assigning every parameter to its Property 
  }
}

### Next Steps

In the CommunityToolkit.Maui.Markup repo, create a New Feature Proposal for each .NET MAUI Control. We need an individual Proposal for each control so that we divide the work into smaller, more manageable PRs, and to ensure we don't forget any controls.

After each Proposal has been created, the Community Toolkit core maintainer team will review the Proposal and help refine the details. The team will then vote to Approve the implementation of each Proposal at our monthly standup.

After each Proposal has been approved, any community member is welcome to submit a PR implementing it.

Extension Methods for .NET MAUI Properties

Believe it or not, this is already an existing goal of CommunityToolkit.Maui.Markup. It currently has extension methods for most Properties, but it is still missing extension methods for many properties.

Implementation

• Create public static class for each .NET MAUI class, eg public static class CollectionViewExtensions
  • See ViewExtensions as an example
• Add a Fluent Extension method that accepts a Generic Type based on the base type, and returns the same Generic Type

Example

Here's an existing example from CommunityToolkit.Maui.Markup for ViewExtensions.CenterHorizontal():

  public static TView CenterHorizontal<TView>(this TView view) where TView : View
  {
      view.HorizontalOptions = LayoutOptions.Center;
      return view;
  }

Next Steps

In the CommunityToolkit.Maui.Markup repo, create a New Feature Proposal for each .NET MAUI Control. We need an individual Proposal for each control so that we divide the work into smaller, more manageable PRs, and to ensure we don't forget any controls.

After each Proposal has been created, the Community Toolkit core maintainer team will review the Proposal and help refine the details. The team will then vote to Approve the implementation of each Proposal at our monthly standup.

After each Proposal has been approved, any community member is welcome to submit a PR implementing it.

[idexus]

@brminnick @mattleibow @pictos @davidortinau @PureWeen

That's why I started a discussion, you can't create a partial class declaration from another assembly.

I didn't want to use XAML, so at the beginning of my journey with MAUI I started using your Community Markup. Unfortunately, I noticed a lot of holes, and that, I don't want to offend anyone here, but things were done in many places very unintuitively, the design lacked coherence. The method-by-method approach of adding functionality to the library scared me. Not only does this result in very slow functionality growth, it actually causes a loss of coherence when these things could be generated.

That's why I decided to create my own library and rely on source generators in it. It took me about 3 weeks to get a usable version. Unfortunately, to add some functionalities, I couldn't do it in a simple way, because you can't add other functionalities to classes besides extension methods. This caused me to subclass. Unfortunately, some classes are sealed, so I had to create a wrapper for them. My library works, but I think it can be done in a simpler and more correct way by implementing some of the functionality in the MAUI core.

I think you should create a new approach, not destroy what is already there, because too much code depends on it. You need to build a solid architecture for the new API, from the ground up. Maybe you will have to abandon the current idea of Community Markup in the future. Many of the things I wrote about earlier should be done with source generators. It's pointless to create tons of extension methods manually when they can be generated. There is a need to meet, to build a solid foundation, and then you can follow them. You can't rely on the community for everything and patch hole by hole. Without solid foundations, good architecture, the project, in my opinion, will be exposed to failure.

The concept of MAUI itself is good, but you need to give people a good tool to make them want to use it in their projects. XAML, no offense, sucks. He ties a man's hands in many places. I think the Fluent API could become a first-class way to develop applications in MAUI, but as I said, it can't be done in a community-only way, without good architecture and of course without full support in the MAUI core.

Otherwise, I'm sorry to say it here, but in the near future, others will be light years ahead of you.

[akhanalcs]

@idexus Perfectly said!

[freever]

@idexus Love your work!

Regarding hot reload, I've been able to get it working using C#-only UIs by using the approach outlined here:
https://dev.to/davidortinau/c-ui-and-net-hot-reload-a-match-made-in-net-maui-243f

[idexus]

@freever Thanks for the hint, now it works even with Visual Studio Hot Reload in Windows :)

example: https://github.com/idexus/HotReloadTest

[idexus]

Regarding hot reload, I've been able to get it working using C#-only UIs by using the approach outlined here: https://dev.to/davidortinau/c-ui-and-net-hot-reload-a-match-made-in-net-maui-243f

@freever when I use this approach there are compilation issues when I use source generators (I use them in my library), and too often VS fails to recompile and asks to restart the application. I decided to create my own hot reload kit. Works under windows and mac. Here is an example of it working with my library.