[Proposal] Add BindingBase support for Bind extension methods to simplify nested bindings

[stephenquan]

Feature name

Add BindingBase support for Bind extension methods to simplify nested bindings

Link to discussion

#416

Link to PR

#417

Progress tracker

• Android Implementation
• iOS Implementation
• MacCatalyst Implementation
• Windows Implementation
• Tizen Implementation
• Unit Tests
• Samples
• Documentation

Summary

This proposal adds a simple Bind overload that accepts a pre-constructed BindingBase, enabling concise, type-safe bindings to nested view model properties. By leveraging the existing BindingBase.Create(...) API, developers can avoid fragile string paths and the verbose manual handler registration required by current expression-based overloads, while preserving fluent Markup syntax. The implementation is minimal, additive, and requires only a single overload that forwards the supplied binding to SetBinding.

Motivation

Binding to nested properties is currently either fragile (string paths) or verbose (manual property change handlers). Since BindingBase.Create(...) already provides type-safe nested property tracking, adding a Bind overload that accepts a BindingBase enables a much simpler and more maintainable syntax while preserving the fluent Markup API.

Detailed Design

Introduce a new Bind overload that accepts a pre-constructed BindingBase instance:

public static partial class BindableObjectExtensions
{
    public static TBindable Bind<TBindable>(
        this TBindable bindable,
        BindableProperty targetProperty,
        BindingBase binding)
        where TBindable : BindableObject
    {
        bindable.SetBinding(targetProperty, binding);
        return bindable;
    }
}

This overload enables any binding created through existing MAUI APIs, such as BindingBase.Create(...), to be used with the fluent Markup syntax:

new Entry().Bind(Entry.TextProperty, BindingBase.Create(static (ViewModel vm) => vm.NestedObject.Text));

Usage Syntax

#### Simple Property Binding

#
new Label().Bind(Label.TextProperty, BindingBase.Create(static (ViewModel vm) => vm.Name));


#### Nested Property Binding


new Entry().Bind(Entry.TextProperty, BindingBase.Create(static (ViewModel vm) => vm.NestedObject.Text));

Drawbacks

The new overload introduces another Bind variation, slightly increasing the API surface area and the number of overloads developers must choose from.

Alternatives

Continue Using String Paths

new Entry().Bind(Entry.TextProperty, "NestedObject.Text");

Or continue using existing expression-based overloads

new Entry().Bind(
    Entry.TextProperty,
    getter: static (ViewModel vm) => vm.NestedObject.Text,
    handlers: ...);

Or use SetBinding directly

entry.SetBinding(Entry.TextProperty, BindingBase.Create(static (ViewModel vm) => vm.NestedObject.Text));

Unresolved Questions

• 1. Should the new overload accept only BindingBase, or should it also support derived binding types through additional generic overloads?
• 2. Are there any overload resolution ambiguities with existing Bind methods when a BindingBase instance is supplied?
• 3. Should documentation and samples be updated to recommend BindingBase.Create(...) as the preferred approach for nested bindings?
• 4. Are there scenarios where BindingBase.Create(...) does not provide equivalent behaviour to the current handler-based overloads, and if so, should those limitations be documented?
• 5. Does the toolkit wish to continue investing in the custom handler-based binding model, or should BindingBase.Create(...) become the primary recommended mechanism for complex binding scenarios?

[stephenquan]

• PR completed and merged: Add BindingBase Bind overload + tests for nested path propagation #417
• Doc Issue completed and merged: Docs: Replace Complex (Nested) Bindings with BindingBase binding MicrosoftDocs/CommunityToolkit#653