[Blazor] Migrating property from one-way to two way binding

[daniel-p-tech]

Hi,

I need to rewrite quite a bit of existing code to implement two-way binding for ActivePageIndex property of one of my complex components that is currently designed only for one way binding. From what I understand, there are two options:

1. Implement setter property and discard Task as stated in the notes sections in this article:

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/data-binding?view=aspnetcore-7.0#binding-to-a-property-with-c-get-and-set-accessors

2. Call await ActivePageIndexChanged.InvokeAsync(ActivePageIndex); after every line of code that modifies the value of ActivePageIndex property.

Which is the proper (clean) approach? I'm currently on .NET 6 but I know that you have been adding new features with respect to binding.

If I choose option 1 (more convenient) what are the repercussions of discarding the Task? Are exceptions going to be swallowed? I need to ensure that any error will propagate to the enclosing ErrorBoundary. There are instances where the ActivePageIndex property is set inside an async void event handler. Again, I know the team has been working on better exception handling.

I want to use the best approach assuming that I will take advantage of all new features available in .NET 7 and upcoming .NET 8.

Thank you for your help!

[Parameter]
public int ActivePageIndex
{
    get => m_activePageIndex;
    set
    {
        if (m_activePageIndex != value)
        {
            m_activePageIndex = value;
            _= ActivePageIndexChanged.InvokeAsync(value);
        }
    }
}

[Parameter]
public EventCallback<int> ActivePageIndexChanged { get; set; }

protected async Task DeleteItem(MouseEventArgs mouseEventArgs, TItem item)
{
    // ...
    ActivePageIndex--;

    // if not using setter, invoke binding this way
    await ActivePageIndexChanged.InvokeAsync(ActivePageIndex);
}

[Xyncgas]

I recommend not use two way binding in blazor, instead use javascript to ask the browser what the current value is, on demand. It avoids the browser talking to .NET too much, honestly speaking

[Xyncgas]

It works well in the long term, if you are building your application using several project, you can skip two way binding only to pass the updated value to the libraries, instead you can write code that use the library directly to say ask the browser for things you want, which can be triggered by listening on the events of elements / components, button pressed keyboard pressed or a timer

no traffic between your browser and .NET if you are not requesting it from browser means you can type text in chat without copying the text to .NET on every stroke

[daniel-p-tech]

Thank you for your suggestion @Xyncgas but I'd like to stay with the built-in Blazor binding mechanism.

@SteveSandersonMS or @javiercn can you spend couple of minutes of your time to answer my question?

Thanks!

[SteveSandersonMS]

Call await ActivePageIndexChanged.InvokeAsync(ActivePageIndex); after every line of code that modifies the value of ActivePageIndex property.

That is almost what I'd recommend, except you shouldn't directly call the setter of an incoming [Parameter] property. See https://learn.microsoft.com/en-us/aspnet/core/blazor/components/overwriting-parameters?view=aspnetcore-7.0

Instead the way you modify your "ActivePageIndex" should be exclusively by calling ActivePageIndexChanged.InvokeAsync(newValue), then the parent component that uses @bind-ActivePageIndex will receive the new value, re-render itself, and in turn cause your child component to be re-rendered with the new ActivePageIndex.

[daniel-p-tech]

Thank you for your explanation.

I have been using ParameterXYZChanged.InvokeAsync(ParameterXYZ) approach in dozens of places in my library/application without any problems - I wasn't aware that this is a potential anti-pattern. It would be very costly to modify the existing code and since I don't see any side effects I will continue using it.