Source generation for BindableProperty when making custom ContentView

[KafkaWannaFly]

Overview

I try to make a custom UI control for my MAUI app and see that I have to make so many boiler-plate codes. I take an example from https://docs.microsoft.com/en-us/dotnet/maui/user-interface/controls/contentview.

public partial class CardView : ContentView
{
    public static readonly BindableProperty CardTitleProperty = BindableProperty.Create(nameof(CardTitle), typeof(string), typeof(CardView), string.Empty);

    public string CardTitle
    {
        get => (string)GetValue(CardView.CardTitleProperty);
        set => SetValue(CardView.CardTitleProperty, value);
    }
    // ...

    public CardView()
    {
        InitializeComponent();
    }
}

You see, for each property, we have to declare a BindableProperty. I think we could auto-generate code like what we're having with BindableObject, ICommand, etc.

I have browsed around but didn't see anything like this so you guys could create one.

API breakdown

[AttributeUsage(AttributeTargets.Field)]
public sealed class BindablePropertyAttribute : Attribute
{

}

Usage example

From the example above but we will re-write like this

public partial class CardView : ContentView
{
    // Basic usage
    [BindableProperty]
    string cardTitle;

    // We may give some initial value
   [BindableProperty("What a lovely day")]
    string cardDescrription;
   
    public CardView()
    {
        InitializeComponent();
    }
}

And the source code is generated would look like this

public partial class CardView : ContentView
{
    public static readonly BindableProperty CardTitleProperty = BindableProperty.Create(nameof(CardTitle), typeof(string), typeof(CardView));

    public string CardTitle
    {
        get => (string)GetValue(CardView.CardTitleProperty);
        set => SetValue(CardView.CardTitleProperty, cardTitle);
    }

    public static readonly BindableProperty CardDescrriptionProperty = BindableProperty.Create(nameof(CardDescrription), typeof(string), typeof(CardView), "What a lovely day");

    public string CardDescrription
    {
        get => (string)GetValue(CardView.CardTitleProperty);
        set => SetValue(CardView.CardTitleProperty, cardDescrription);
    }
}

Breaking change?

No

Alternatives

I try but can't find any

Additional context

The need for this feature occurs when we want to create a custom UI component and expose some of its fields as mentioned above

Help us help you

No, just wanted to propose this

[Sergio0694]

Transferring this to the MAUI toolkit, since BindableProperty is MAUI-specific, and not a general .NET API 🙂

[pictos]

Thanks @Sergio0694 .

@KafkaWannaFly does this API looks good fir you?
https://github.com/pictos/BindablePropertySG#uso

[bijington]

I believe @matt-goldman was also keen to see something like this

[KafkaWannaFly]

Hi @pictos
I have checked your repo. This is similar to what I'm looking for but the API has a few problems:

1. The amount of code is nearly as much as the old way
2. Prop's name is defined by a string, which would make things a little bit inconvenient for renaming

[pictos]

Prop's name is defined by a string, which would make things a little bit inconvenient for renaming

@KafkaWannaFly we can't use nameof in attributes, yet. But when C# 11 came out this will be possible

I believe that any solution will be verbose, if you do BindableProperty.Create or BindablePropert.CreateAttached you will see in the helper that you can provide a tons of parameters and we should support all of them. Of course we can repeate the defaults for parameters that the dev doesn't want to provide, but at the end of the day it will be verbose, or am I missing something?

[KafkaWannaFly]

we can't use nameof in attributes, yet. But when C# 11 came out this will be possible

@pictos Thanks for your answer. It makes sense a lot. I guess we have to bear it for a while.

[matt-goldman]

I believe @matt-goldman was also keen to see something like this

This will be an awesome addition. Making reusable components is a staple of any modern UI framework, and it's significantly more laborious in .NET MAUI than in other frameworks. Look at how Blazor does it for example with the [Parameter] attribute. Much easier. Angular also has a much easier way to do it using @Input for example.

There's a lot of boilerplate in .NET MAUI to achieve comparatively simple tasks in other frameworks. This will get my absolute support and I would be happy to help any way I could.

[pictos]

Some ideas on how to implement it and don't.

At first, it was suggested to create a field and use it to "store" the attribute and generate the BP. Like this snippet

// User code this
 [BindableProperty]
 string cardTitle;

TBH I don't like this approach at first glance because the compiler-generated code will not remove those fields, since they are used by the Attributes, can these fields have any perf impact? Like increasing the size of the class? Maybe for one class we don't feel this but imagine a large mobile app with a lot of custom controls.

Instead, I would suggest using something that will be used (method, ctor and/or class) so I thought of a couple of ways of doing it:

1. Using attributes at the class level

The class will be there and will be used, so we can take advantage of that:

 [BPSourceGen.BPCreation(PropertyName = "CardTitle", ReturnType = typeof(string), OwnerType = typeof(CardView), DefaultValue = string.Empty, PropertyChangedMethodName = "Invalidate")]
 [BPSourceGen.BPCreation(PropertyName = "CardDescription", ReturnType = typeof(string)]
public partial class CardView : ContentView 
{
       public static void Invalidate() { }  // OnPropertyChanged method
}

The CardTitle has a more complete implementation and the CardDecription has just only the basic info that is needed to create the BindableProperty.

2. Using attributes at the ctor level

public partial class CardView : ContentView 
{

       [BPSourceGen.BPCreation(PropertyName = "CardTitle", ReturnType = typeof(string), OwnerType = typeof(CardView), DefaultValue = string.Empty, PropertyChangedMethodName = "Invalidate")]
       [BPSourceGen.BPCreation(PropertyName = "CardDescription", ReturnType = typeof(string)]
       public CardView() { }

       public static void Invalidate() { }  // OnPropertyChanged method
}

The same as the 1 but now we decorate the ctor .

3. Using attributes at PropertyChanged method

This is an addition to the last suggestions, so let's say that the user will implement the PropertyChanged delegate then this method can be decorated in order to create the BP and reduce the noise at the Class or Ctor level.

public partial class CardView : ContentView 
{

       [BPSourceGen.BPCreation(PropertyName = "CardDescription", ReturnType = typeof(string)]
       public CardView() { }


       [BPSourceGen.BPCreation(PropertyName = "CardTitle", ReturnType = typeof(string), OwnerType = typeof(CardView), DefaultValue = string.Empty)]
       public static void Invalidate() { }  // OnPropertyChanged method
}

[matt-goldman]

This is great, but I don't think it reduces the amount of boilerplate code enough. I understand your concerns re blowing out class sizes. Personally, I was really hoping for something that reduces boilerplate and makes it easier and more appealing for new developers. For instance compare what we do now in .NET MAUI to create a bindable property to Blazor:

[Parameter]
public string MyParam { get; set; }

or even Angular:

@Input
myparam = '';

Is there a possibility of offering both approaches? The simple attribute for quick scenarios, and then another approach like you're suggesting for cases where people find the fields are causing a performance impact?

[pictos]

I don't think that we can have a partial Property in C#. Just a friendly reminder, Roslyn SG can't modify the user code (like Fody does) it can just add code. In order to make it like Blazor, I would say that the .NET MAUI team needs to support that syntax first.

About the boilerplate, we need to support all parameters that the BindableProperty.Create method has, and force the user to provide the arguments that don't have a default value or we can't infer (like the ReturnType).

[matt-goldman]

Yeah you're right we can't have partial properties, I was showing the Blazor and Angular approach to show how easy it is in those frameworks compared to .NET MAUI rather than suggesting that's what we should be doing here (although yes I do agree it would be great if the .NET MAUI team could support that syntax).

About the boilerplate, we need to support all parameters that the BindableProperty.Create method has, and force the user to provide the arguments that don't have a default value or we can't infer (like the ReturnType).

Does it need to support everything that you can do with BindableProperty.Create? Couldn't it just be a simple alternative for simple scenarios, and if you need more complexity or fine-grained control, just use BindableProperty.Create? Otherwise what's the advantage of using something like this rather than just using BindableProperty.Create?

[pictos]

@matt-goldman the idea is to support everyone, not sure if you read all my spec, but there's one sample where you, as a developer, don't need to inform all the types, I'll paste the simple version here.
[BPSourceGen.BPCreation(PropertyName = "CardDescription", ReturnType = typeof(string)]

As you can see there are just two required arguments, IMHO this is a good size for a sample need. What do you think?

[VladislavAntonyuk]

I use this lib: https://github.com/rrmanzano/maui-bindableproperty-generator

[matt-goldman]

That's really cool

[KafkaWannaFly]

I also come to this implementation for the idea: https://github.com/KafkaWannaFly/BindableProps
We can infer many information for required parameters from field declaration. The only concern left is that we might never use the member fields but I guest we have to live with that.

[Riccardo11]

I'm writing a library that perfectly fits in this thread's title, but aims to do something slightly different. I give an example to explain that.

Let's say that inside your ContentView there is an Entry and you want to bind its Text property.

I created an attribute that, applied to the custom control class and given some required parameters, creates a bindable property linked to the Text property of the Entry.

Link to the repo: https://github.com/Riccardo11/CCPropGen.

This is a code example.

using Maui.CCPropGen;

namespace CCPropGen.Maui.Demo;

// Attribute parameters:
// - Control name
// - Control type
// - Property name
// - Property type
[CCPropGen("EntryControl", typeof(Entry), "Text", typeof(string))]
public partial class CCPropGenEntry : ContentView
{
    public CCPropGenEntry()
    {
        InitializeComponent();
        
        // Currently needed to set binding contexts correctly
        InitializeCCPropGen();
    }
}

It's far from being ready to be used in a real environment, but I would appreciate your thoughts about it.

[CliffAgius]

Closed as per the Community Stand-up discussion here: https://youtu.be/N9wMcBP4jtg?t=2889

[h0lg]

@CliffAgius Could you please clarify the actual reason for closing this issue here? Even though I sat through enough stand-ups for my taste, I listened to yours for a few minutes - but couldn't parse that info out of there. Thanks!

[CliffAgius]

The idea is as a community toolkit for the maintainers to look at something we decided that it needs the backing of the community so we are not just adding random stuff. We have did in that standup that a feature needs to get 10+ up votes or we will close it after 6 months. This feature has been open for over a year and only got a few up votes so the community are not behind it and this it was closed.

If the community want the feature we can reopen and reassess.

As a small team we are picking what we work on based on the community wishes.

[CliffAgius]

This was talked about on the Community Meet-up chat for July 2024 and it agreed this would be re-opened and we will look at the PR from @pictos and see if it solves the need.

[TheCodeTraveler]

Here's the PR we merged implementing it internally: #1321

[CliffAgius]

As PR #1321 has been implemented internally for the maintainers to dogfood and it has been discussed on the September monthly stand-up I am closing this discussion at this time.