Use Partial Methods for BindableProperty Source Generator

[tranb3r]

First of all, thank you for adding the BindableProperty source generator to CommunityToolkit.Maui — it’s a great addition and a big step forward for reducing boilerplate.

I’d like to start a discussion around a possible developer experience (DevEx) improvement regarding how PropertyChanged is handled in the generator.

Current behavior (CommunityToolkit.Maui)

Today, reacting to property changes requires explicitly specifying a static method and dealing with BindableObject casts:

[BindableProperty(PropertyChangedMethodName = nameof(OnMyPropertyChanged))]
public partial string MyProperty { get; set; }

private static void OnMyPropertyChanged(
    BindableObject bindable,
    object oldValue,
    object newValue)
{
    var myControl = (MyControl)bindable;
    var value = (string)newValue;
    myControl.DoSomething(value);
}

This is perfectly functional and efficient, but it exposes a lot of framework-level complexity to the consumer:

• Explicit method name wiring
• Static method requirement
• Manual casting of BindableObject and object

Proposed alternative (partial method pattern)

Inspired by:

• CommunityToolkit.Mvvm observable properties
• Other existing SG implementations (e.g. SQuan.Helpers.Maui.Mvvm)

The idea is to allow an optional partial method with a strongly-typed signature:

[BindableProperty]
public partial string MyProperty { get; set; }

partial void OnMyPropertyChanged(string value)
{
    DoSomething(value);
}

Benefits

• Strongly typed
• No casts
• No explicit delegate wiring
• Consistent with CommunityToolkit.Mvvm patterns
• Much simpler mental model for consumers

Nobody would be forced to use it — this would be an opt-in convenience.

Known concerns (from discussion on Discord)

Delegate allocation and performance

It was pointed out that:

• BindableProperty.PropertyChanged requires a delegate
• Even if unused, assigning a delegate implies allocation and invocation cost
• This differs from MVVM observable properties, where the logic is inside the property setter that must exist anyway

This is a valid concern and the main technical objection raised so far.

Generator complexity

One possible mitigation is:

• Detecting whether the partial method is actually implemented
• Only wiring the delegate if it exists

This introduces:

• More generator logic
• Potential performance impact during generation
• Edge cases with overloads or multiple signatures

So the question becomes whether the DevEx gain justifies the added complexity.

Why I still think it’s worth discussing

• The DevEx difference is very noticeable, especially for developers already familiar with CommunityToolkit.Mvvm
• Consistency of patterns across toolkits matters, even if the underlying generated code differs
• The current implementation is not bad — this is not a criticism, but an exploration of possible evolution

Open questions for the team

• Would a partial-method-based PropertyChanged hook be acceptable as an optional feature?
• Is the delegate allocation concern a hard blocker, or could it be mitigated?
• Is DevEx consistency with ObservableObject considered a goal here, or is Maui a fundamentally different space?

I’m not advocating for an immediate change, but I think this tradeoff is worth discussing openly.

Thanks for reading 👍

[stephenquan]

Your new discussion is similar to the non-static method discussions and PR:

• non-static method discussion: BindableProperty PropertyChangedMethodType attribute enhancement #3001
• non-static method PR: BindableProperty non-static method name enhancement #3002 (comment)
• 2026 January Standup: https://github.com/CommunityToolkit/Maui/wiki/2026-January-Standup

[tranb3r]

After reviewing #3001 and PR #3002 and the standup video, I see my proposal mostly as a complement to the original request rather than a separate or competing idea. Both approaches aim to remove the need for user-authored static methods for all BindableProperty callbacks, but my suggestion goes one step further by proposing to drop explicit attribute parameters entirely and rely on convention-based instance method names, similar to the patterns used in CommunityToolkit.Mvvm.

I created this discussion following a suggestion on discord from @pictos, who also participated in the earlier discussion, with the intent of helping clarify the scope and potentially move the conversation forward rather than reopening settled topics.

At this point, I’d mainly like to understand where things stand today: whether the team still sees value in this feature, if there is active interest in pursuing it, and what the current plan or direction might be.

More concretely, should we aim to converge on a single approach, iterate further on the design, or close the proposal for now?

[stephenquan]

@tranb3r did you see my partial method addition? #3001 (comment)

[tranb3r]

Yes. Love it. Although it still requires a parameter or an attribute to point to the method, right? Or am I missing something?

[stephenquan]

I considered the feedback on CommunityToolkit.Maui’s BindableProperty implementation and its performance implications. This new approach provides the best of both worlds: developers can still use the original static pattern for maximum optimization, or opt into a leaner non‑static model. The attributes make it easy to choose whichever workflow they prefer.

[tranb3r]

Do we need the attribute? Both CommunityToolkit.Mvvm and Squan.Helpers source generators find On{PropertyName}Changed methods without having to add an attribute.

[stephenquan]

@tranb3r I am the author of SQuan.Helpers.Maui.Mvvm, but its design was heavily influenced by the ObservableObject/ObservableProperty from CommunityToolkit.Mvvm 8.4.0 implementation. Regarding CommunityToolkit.Maui, I understand why the initial [BindableProperty] approach is a passthrough to static methods, and that static methods allow better compiler optimizations. We don’t want a design that loses those benefits, which is why having an opt‑in mechanism when needed makes sense.

[tranb3r]

I know.
My question is: does the source generator really need an attribute to find the method when it exists? or could the SG look for the method based on its name, and if it exists, then it implicitely means that the user has "opted-in" to this mechanism.

[stephenquan]

Playing devil's advocate, there is some merit in keeping the current [BindableProperty] PropertyChangedMethodName as is, since it's reusable and consistent with [AttachedBindableProperty]. And in your example, there is hardly any difference in the code needed to call DoSomething(string value), for example:

[BindableProperty(PropertyChangedMethodName = nameof(OnMyPropertyChanged))]
public partial string MyProperty { get; set; }

static void OnMyPropertyChanged(BindableObject b, object o, object n) => ((MyControl)b).DoSomething((string)n);

If you look at how .NET MAUI implements the FontImageSource.ColorProperty propertyChanged handler, the pattern is essentially the same: https://github.com/dotnet/maui/blob/c1776170f994239c2a458e1615f9a8099c66de81/src/Controls/src/Core/FontImageSource.cs#L14

[tranb3r]

The MAUI code you reference is framework-internal and does not use source generators, so in that context the pattern makes sense.
However, this discussion is specifically about using source generation to hide that verbosity and improve developer experience.

I was also a bit surprised, given that your own package (SQuan.Helpers.Maui.Mvvm) already implements this kind of simplification.
Has your position on this changed, or are there specific reasons why you wouldn’t support a similar approach in the Toolkit?