RadzenTemplateForm invokes Submit callback with null when using EditContext instead of Data #806

Closed
opened 2026-01-29 17:44:41 +00:00 by claunia · 3 comments
Owner

Originally created by @Flachdachs on GitHub (Apr 9, 2023).

You can use a RadzenTemplateForm with Data="someDataObject" and everything works fine. Instead of Data you can also use an EditContext where Model is set to someDataObject. EditContext provides some useful events when you want to react on e.g. field changes. You only need to assign a single event handler instead of doing this for every form field. This works well so far, except ...

Describe the bug

... when you submit the form the Submit callback is called with null instead of the changed model.

To Reproduce

<RadzenTemplateForm TItem="Data" EditContext="editContext" Submit="saveData">
    <RadzenTextBox Name="@nameof(Data.Field)" @bind-Value="@model.Field"/>
    <RadzenButton Text="Save"/>
</RadzenTemplateForm>
@code {
    private Data model;
    private EditContext editContext;

    protected override void OnInitialized() {
        model = new Data("foo");
        editContext = new EditContext(model);
    }

    private void saveData(Data formData) {
        // formData is null, but both model and editContext.Model have the actual form data
    }

    record Data(string Field);
}

Expected behavior
When the parameter Data is not set but EditContext is given then set Data to (TItem)EditContext,Model in OnParametersSet.
Or, in OnSubmit call await Submit.InvokeAsync((TItem)EditContext.Model).

Originally created by @Flachdachs on GitHub (Apr 9, 2023). You can use a `RadzenTemplateForm` with `Data="someDataObject"` and everything works fine. Instead of Data you can also use an `EditContext` where `Model` is set to `someDataObject`. `EditContext` provides some useful events when you want to react on e.g. field changes. You only need to assign a single event handler instead of doing this for every form field. This works well so far, except ... **Describe the bug** ... when you submit the form the `Submit` callback is called with `null` instead of the changed model. **To Reproduce** ```razor <RadzenTemplateForm TItem="Data" EditContext="editContext" Submit="saveData"> <RadzenTextBox Name="@nameof(Data.Field)" @bind-Value="@model.Field"/> <RadzenButton Text="Save"/> </RadzenTemplateForm> @code { private Data model; private EditContext editContext; protected override void OnInitialized() { model = new Data("foo"); editContext = new EditContext(model); } private void saveData(Data formData) { // formData is null, but both model and editContext.Model have the actual form data } record Data(string Field); } ``` **Expected behavior** When the parameter Data is not set but EditContext is given then set Data to `(TItem)EditContext,Model` in OnParametersSet. Or, in OnSubmit call `await Submit.InvokeAsync((TItem)EditContext.Model)`.
Author
Owner

@akorchev commented on GitHub (Apr 12, 2023):

You can easily use your model field in your example. If Data isn't set you shouldn't expect it in the Submit event handler.

@akorchev commented on GitHub (Apr 12, 2023): You can easily use your model field in your example. If Data isn't set you shouldn't expect it in the Submit event handler.
Author
Owner

@Flachdachs commented on GitHub (Apr 12, 2023):

Same logic applies to Data. When using Data you also can use the reference to this object and don't need the argument in the submit handler. Why is there an inconsistent behavior when the fix is easy?

My expectation isn't bound to Data, but that a parameter of a submit handler has always the values of the form.

@Flachdachs commented on GitHub (Apr 12, 2023): Same logic applies to Data. When using Data you also can use the reference to this object and don't need the argument in the submit handler. Why is there an inconsistent behavior when the fix is easy? My expectation isn't bound to Data, but that a parameter of a submit handler has always the values of the form.
Author
Owner

@akorchev commented on GitHub (Apr 12, 2023):

You are right. We would accept a pull request with this suggestion implemented.

@akorchev commented on GitHub (Apr 12, 2023): You are right. We would accept a pull request with this suggestion implemented.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/radzen-blazor#806