Still running into problems utlizing OnChange event in Blazor

@can kucukgultekin I tried to add a follow-up question, but this website refused to let me enter another comment. Therefore, I'm asking my question as an "answer" to my question.

Your answer has helped me get close, but I've still got a problem. When I made the adjustments to my Blazor component, the code-behind to the Blazor component, and the TimetrackDTO object, I now get this error message whenever I go to the page that the component is hosted on:

InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter, please provide one of these. Microsoft.AspNetCore.Components.Forms.EditForm.OnParametersSet()

The EditForm in my Blazor component now looks like this:

<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

In the OnInitializedAsync method in the component's code-behind, I have this:

            editContext = new EditContext(timetrackDTO);
            editContext.OnFieldChanged += HandleFieldChanged;

In another place in the code behind I have this:

        private void HandleFieldChanged(object? sender, FieldChangedEventArgs e)
        {
            var fieldName = e.FieldIdentifier.FieldName;
            var fieldValue = e.FieldIdentifier.Model.GetType()
                .GetProperty(e.FieldIdentifier.FieldName)?
                .GetValue(e.FieldIdentifier.Model);
            Console.WriteLine($"Field '{fieldName}' changed to: {fieldValue}");   // Log the new value
            StateHasChanged();
        }

        protected override async Task OnParametersSetAsync()
        {
            timetrackDTO.Userid = UserId;
            timetrackDTO.SelectedTaskId = 0;
            IsButtonDisabled = CanSubmit();
            await Task.CompletedTask;
        }

And finally, in the TimetrackDTO class I put in this:

    private int _selectedTaskId;
    // Put here so the EditContext in the InputTimeComp.razor.cs can bind to it directly
    public int SelectedTaskId 
    { 
        get => _selectedTaskId;
        set
        {             
            if (_selectedTaskId != value)
            {
                _selectedTaskId = value;
                OnTaskChanged();
            }
        }
    }
// later

    private void OnTaskChanged()
    {
        Console.WriteLine($"Task changed to: {SelectedTaskId}");
        ComponentBase.StateHasChanged();
    }

However, StateHasChanged() isn't recognized, even when I put in a using Microsoft.AspNetCore.Components.

So, what's wrong and how do I fix it?

Hi Falanga, Rod, DOH,

the follow-up makes sense, and what you're seeing now boils down to two separate issues:

the EditForm exception

trying to call StateHasChanged() from inside your DTO

Let me tackle them one by one.

The EditForm error:

InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter, please provide one of these.

means that at render time both Model and EditContext are effectively null. In your markup you've switched to:

<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

If editContext hasn't been initialized yet, Blazor sees that as "no EditContext provided" and throws.

The canonical pattern for this looks like:

using Microsoft.AspNetCore.Components.Forms;

private EditContext? editContext;
private TimetrackDTO timetrackDTO = new();

protected override void OnInitialized()
{
    editContext = new EditContext(timetrackDTO);
    editContext.OnFieldChanged += HandleFieldChanged;
}

and in the razor:

<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />
    ...
</EditForm>

Key details to double-check:

editContext is a field, not an expression-bodied property. You should no longer have something like:

private EditContext editContext => new EditContext(timetrackDTO); // this is the old, broken pattern

OnInitialized (or protected override async Task OnInitializedAsync()) is actually overriding the base method, so Blazor calls it before the first render and sets editContext.

You don't replace timetrackDTO with a new instance later; you only change its properties. Your OnParametersSetAsync that does

timetrackDTO.Userid = UserId;
timetrackDTO.SelectedTaskId = 0;
IsButtonDisabled = CanSubmit();

is fine in that regard.

Once editContext is a single non-null instance created in OnInitialized* and passed via EditContext="@editContext", the "EditForm requires Model or EditContext" exception should go away.

Now about StateHasChanged() inside the DTO.

This code:

private int _selectedTaskId;

public int SelectedTaskId 
{ 
    get => _selectedTaskId;
    set
    {             
        if (_selectedTaskId != value)
        {
            _selectedTaskId = value;
            OnTaskChanged();
        }
    }
}

// later
private void OnTaskChanged()
{
    Console.WriteLine($"Task changed to: {SelectedTaskId}");
    ComponentBase.StateHasChanged();
}

runs into two problems:

TimetrackDTO is just a model class, it doesn't derive from ComponentBase, so it has no StateHasChanged() method. And StateHasChanged() is an instance method, not a static one – there is no ComponentBase.StateHasChanged() to call.

Architecturally, you don't want your DTO to know about UI concerns. The model shouldn't be telling the component to re-render.

The place where you do have access to StateHasChanged() is the component itself, and you're already wiring up EditContext.OnFieldChanged there. That's exactly where you can react to SelectedTaskId changing.

You can simplify the DTO:

public int SelectedTaskId { get; set; }

and move the "task changed" behavior into HandleFieldChanged:

private void HandleFieldChanged(object? sender, FieldChangedEventArgs e)
{
    var fieldName = e.FieldIdentifier.FieldName;

    if (fieldName == nameof(TimetrackDTO.SelectedTaskId))
    {
        Console.WriteLine($"Task changed to: {timetrackDTO.SelectedTaskId}");
        // any extra logic you want when the task changes
    }

    var fieldValue = e.FieldIdentifier.Model.GetType()
        .GetProperty(e.FieldIdentifier.FieldName)?
        .GetValue(e.FieldIdentifier.Model);

    Console.WriteLine($"Field '{fieldName}' changed to: {fieldValue}");
    StateHasChanged();
}

Now:

EditContext tracks timetrackDTO.SelectedTaskId,

HandleFieldChanged is called when it changes,

and StateHasChanged() is invoked from the component, where it actually exists.

So the practical fix is:

Ensure editContext is a single field initialized once in OnInitialized/OnInitializedAsync, and passed via EditContext="@editContext".

Remove OnTaskChanged / ComponentBase.StateHasChanged() from the DTO; keep the DTO dumb, and handle "task changed" logic in the component (HandleFieldChanged or @bind-Value:after) where you have access to StateHasChanged().

With those pieces in place you should no longer see the InvalidOperationException, and your InputSelect changes will trigger the handlers as expected.

@can kucukgultekin There's some interesting changes there. I've changed the instantiation of timetrackDTO to private TimetrackDTO timetrackDTO = new() just as you instructed. Then I followed your other changes by removing the StateHasChanged() from timetrackDTO to the calling Blazor component, etc. However, I am still getting the System.InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter, please provide one of these. error. I even added logic in the OnInitializedAsync method to make sure that editContext is only instantiated once:

            if (editContext is null)
            {
                editContext = new EditContext(timetrackDTO);
                editContext.OnFieldChanged += HandleFieldChanged;
            }

that may not be necessary, but I figured it couldn't hurt.

Thank you for your help.

@Falanga, Rod, DOH,

thanks for the follow-up, and nice work cleaning up the DTO and StateHasChanged part.

At this point the remaining error:

System.InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter

basically means: when EditForm is rendered, both Model and EditContext are still null. In your case that implies editContext is still null at the moment the markup

<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">

is first evaluated.

Your extra guard with if (editContext is null) is fine, but the exception isn’t about "creating it more than once", it’s about "it doesn’t exist yet when the form renders".

With OnInitializedAsync there’s a small but important lifecycle detail: any code that runs before the first await executes before the first render, but anything after the first await only runs later and triggers a re-render. If editContext is only created after an await inside OnInitializedAsync, the first render will still see it as null and EditForm will throw.

You can fix this in a few ways.

1. Create the EditContext synchronously before the first render (use OnInitialized instead of OnInitializedAsync):

private EditContext? editContext;
private TimetrackDTO timetrackDTO = new();

protected override void OnInitialized() // not async
{
    editContext = new EditContext(timetrackDTO);
    editContext.OnFieldChanged += HandleFieldChanged;
}

Keep your EditForm as:

<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />
    ...
</EditForm>

Because OnInitialized runs before the first render completes, editContext is non-null when EditForm renders and the exception goes away. This is the simplest option.

2. Or: still use OnInitializedAsync, but create editContext before any await:

private EditContext? editContext;
private TimetrackDTO timetrackDTO = new();

protected override async Task OnInitializedAsync()
{
    if (editContext is null)
    {
        editContext = new EditContext(timetrackDTO);
        editContext.OnFieldChanged += HandleFieldChanged;
    }

    // any async work comes after this
    await LoadDataAsync();
}

as long as the new EditContext(...) line is before the first await, editContext will be ready for the first render as well.

3. Gate the markup on editContext being non-null:

If you really want to be extra safe (or you do more complex async work), you can prevent the form from rendering until editContext is set:

@if (editContext is null)
{
    <p>Loading...</p>
}
else
{
    <EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">
        <DataAnnotationsValidator />
        <ValidationSummary />
        ...
    </EditForm>
}

With this pattern, even if `editContext` is created later, `EditForm` never sees a null context, so the `InvalidOperationException` can’t occur. The downside is a small "loading" flicker.

Also double-check one more thing in your Razor markup: make sure you’re using the EditContext parameter, not the Model parameter. It should be:

<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">

not:

<EditForm Model="@editContext" OnValidSubmit="HandleValidSubmit">

The Model parameter expects the data model object, not an EditContext instance.

To debug this, you can temporarily add this line right before the form:

<p>EditContext is null: @(editContext == null)</p>
<EditForm EditContext="@editContext" OnValidSubmit="HandleValidSubmit">

If you see true when the page first loads, that confirms editContext is null at render time.

Bottom line: make sure editContext is a single field

private EditContext? editContext;

(no remaining private EditContext editContext => new EditContext(...) expression-bodied property anywhere), and initialize it either in OnInitialized (simplest), or at the very top of OnInitializedAsync before any await, or keep OnInitializedAsync and wrap the EditForm in an @if (editContext is null) check. Once EditForm only renders when editContext has a real instance, the "requires Model or EditContext" exception should finally disappear.

WOW, that is more complicated than I thought!! Initially I tried to use OnInitialized instead of OnInitializedAsync however, that complained about the await call I am making to a Minimal API I'd written to do the database work. So, I chose the second option and moved the initialization of editContext as the first action performed in the OnInitializedAsync call. That worked! But, boy, I would never have thought of that!!