Confused about Blazor two-way data binding with collections and complex objects

[UniMichael]

I've gone through the Blazor data binding documentation, but I'm confused about how complex objects and lists (of complex objects) are meant to work with data binding.

Imagine the following scenario:

You have an Address class and a Person class:

public class Address
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public string Country { get; set; } = string.Empty;
    public string Street { get; set; } = string.Empty;
    // ...
}

public class Person
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public string Name { get; set; } = string.Empty;
    // ...

    public List<Address> Addresses { get; } = [];
}

Let's say I want to create a re-usable component that modifies a Person instance and its addresses. Maybe this component has some built-in validation for its fields, or runs some kind of logic when certain properties are updated.

What's the recommended approach to take here?

Right now I've been toying with the following approach:

@* AddressComponent.razor *@

<input type="text" @bind:get="Address.Country" @bind:set="HandleCountryChangedAsync" />
@* Inputs for other properties here... *@

@code {
    [Parameter]
    public Address Address { get; set; } = null!;

    [Parameter]
    public EventCallback<Address> AddressChanged{ get; set; }

    private async Task HandleCountryChangedAsync(string countrye)
    {
        Address.Country = country;
        await AddressChanged.InvokeAsync(Address);
    }
}

@* PersonComponent.razor *@

<input type="text" @bind:get="Person.Name" @bind:set="HandleNameChangedAsync" />
@* Inputs for other properties here... *@

@foreach(var (address, index) in Person.Addresses.Select((a, i) => (a, i)))
{
    <AddressComponent @bind-Address:get="address" @bind-Address:set="HandleAddressChangedAsync" />
    @* Imagine it had other handlers for the other properties. *@
}

@code {
    [Parameter]
    public Person Person { get; set; } = null!;

    [Parameter]
    public EventCallback<Person> PersonChanged { get; set; }

    private async Task HandleNameChangedAsync(string name)
    {
        // Some validation logic here with an early return if needed...

        Person.Name = name;
        await PersonChanged.InvokeAsync(Person);
    }

    private async Task HandleAddressChangedAsync(Address address)
    {
        // Some validation logic here with an early return if needed...

        var index = Person.Addresses.FindIndex(a => a.Id == address.Id);
        Person.Addresses[index] = address;
        await PersonChanged.InvokeAsync(Person);
    }
}

@* MyPageComponent.razor *@

<PersonComponent @bind-Person="_person" />

@code {
    private Person _person = new();

    // ...
}

This is how it would work in something like React, where the top-level component has the state, and either wraps its setState() function in more specialized callbacks or passes it outright to its children so they can update the nested-state properly.

With this approach, we need to explicitly "bubble up" our nested property change events, though.

This seems to work (and I've been considering using records instead of classes so I can use the with keyword to create copies with only the affected property being changed), but it still feels weird.

Our components update the parameter's properties directly, and then signal to the parent that the parameter itself should be changed (even though it hasn't). I've added Console.WriteLine()s to most of our components to track how the lifecycle methods trigger when I make a change, and the whole component hierarchy re-renders (which makes sense when the top-level component is told to update its bound [Parameter]). I don't know enough about Blazor's inner workings to know if this is problematic or not.

The only alternative I've been able to think of for cases with complex objects is to have a flattened model and individually bind every property. But that doesn't really work if I have a list with an unknown size. One approach I've seen people take with lists is to just keep it at the top-level and bind the individual values, but that doesn't really solve the issue of having a list of complex objects or a complex objects with lists inside of it.

Data binding's easy enough with trivial models and data types, but it seems to fall apart with collections and complex objects, and the documentation doesn't seem to offer guidance on how to deal with this.

So what's the recommended approach for this?

[UniMichael]

Found an issue with this approach. Unfortunately, <EditForm>'s internal EditContext gets re-created when you update the model, which leads to a complete loss of validation state whenever a property is updated.

I'd really appreciate if someone could comment on the recommended approach for binding complex objects. As it stands, Blazor seems too immature for any serious project if it can't handle a simple use case like dealing with objects.