Forms and EditForm

Analogy categoryAnalogies

EditForm is Blazor's wrapper component for building forms; you give it either a Model parameter (an object instance) or an EditContext parameter (never both), and it constructs or reuses an EditContext internally and cascades it down to every child input component via CascadingValue. That shared EditContext is what lets InputText, InputNumber, and other built-in inputs, along with the validation system, all agree on which object and which fields they're working with, and it's what OnValidSubmit checks before invoking your handler.

🏏

Cricket analogy: Like a team huddle where the captain cascades the game plan to every fielder before play starts, EditForm cascades its EditContext down to every input component inside it, and fires OnValidSubmit only once all fields pass validation.

Built-in Input Components

Blazor ships built-in input components, InputText, InputNumber, InputSelect, InputCheckbox, and InputDate among others, that two-way bind a model property via @bind-Value and automatically wire themselves into the surrounding EditContext. As the user interacts with a field, Blazor toggles CSS classes on the rendered element, modified once the value changes from its initial state, and valid or invalid once that field has been validated, giving you free styling hooks without writing manual state-tracking code.

🏏

Cricket analogy: Like a scoreboard operator updating the display the instant a run is scored, InputNumber's @bind-Value updates the bound model property immediately on change, and Blazor applies CSS classes like modified and valid to reflect field state, similar to a scoreboard flashing green after a boundary.

EditContext and Field State

EditContext tracks per-field modification state internally: calling EditContext.IsModified(fieldIdentifier) tells you whether a specific field has changed since the form was initialized or last marked clean, and MarkAsUnmodified() resets that tracking, which is typically called right after a successful save so the form doesn't keep flagging already-persisted changes as dirty.

🏏

Cricket analogy: Like a scorer marking which overs have been amended after a review overturns a decision, EditContext.IsModified(fieldIdentifier) tracks exactly which fields changed, and MarkAsUnmodified resets that flag once a form is saved.

Calling EditContext.Validate() explicitly re-runs every registered validator (including DataAnnotations) against the whole model and returns a bool indicating overall success, which is what OnValidSubmit does internally before invoking your callback. For finer-grained reactions, subscribing to EditContext.OnFieldChanged lets a component respond the instant any single field's value changes, useful for live character counters or conditionally showing dependent fields.

🏏

Cricket analogy: Like a third umpire re-checking every angle only when a review is formally requested, calling EditContext.Validate() explicitly re-runs every validator, while subscribing to OnFieldChanged lets a component react instantly as each single field changes, like a scorer updating live as each ball is bowled.

razor

<EditForm Model="@enrollment" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <label>Full name</label>
    <InputText @bind-Value="enrollment.FullName" />

    <label>Age</label>
    <InputNumber @bind-Value="enrollment.Age" />

    <button type="submit">Enroll</button>
</EditForm>

@code {
    private EnrollmentModel enrollment = new();

    private void HandleValidSubmit()
    {
        EnrollmentService.Save(enrollment);
    }
}

EditForm requires exactly one of its Model or EditContext parameters to be set, never both. Passing both, or neither, throws an InvalidOperationException at render time. Use Model for the common case of a single bound object; use EditContext directly when you need to construct and control the EditContext yourself, for example to share it across multiple sibling components.

Submit Handling

EditForm exposes three submit callbacks: OnValidSubmit fires only after EditContext.Validate() succeeds, OnInvalidSubmit fires only when it fails, and the more general OnSubmit fires unconditionally on every submit attempt, leaving validation entirely up to your handler, which is useful when you want custom control, such as saving a draft even when some fields are incomplete.

🏏

Cricket analogy: Like a bowler only being allowed to appeal once the umpire confirms all conditions for a valid delivery are met, OnValidSubmit only fires after EditContext confirms every validator passed, while OnSubmit always fires and leaves validation entirely to your own code.

Mutating the bound model's properties directly from code outside the normal input-binding pathway (for example, resetting a property in a background timer callback) does not automatically notify the EditContext, so validation CSS classes and ValidationMessage components can go stale. Also, binding EditForm to an immutable record with init-only properties breaks @bind-Value's two-way binding entirely, since the setter Blazor needs to write back into doesn't exist; use a mutable class or a mutable DTO for the bound Model.

EditForm takes exactly one of Model or EditContext and cascades a shared EditContext to all child input components.
Built-in inputs like InputText and InputNumber two-way bind via @bind-Value and automatically apply modified/valid/invalid CSS classes.
EditContext.IsModified and MarkAsUnmodified track and reset per-field dirty state.
EditContext.Validate() runs a full validation pass; OnFieldChanged reacts to individual field edits in real time.
OnValidSubmit fires only after validation succeeds; OnInvalidSubmit fires only on failure; OnSubmit fires unconditionally.
The bound Model must be a mutable type; init-only record properties break two-way binding.
Mutating the model outside the binding pathway can leave validation UI out of sync with actual state.

Practice what you learned

1. What happens if you set both Model and EditContext on an EditForm?

2. Which EditForm callback fires only after all validators pass?

3. What does EditContext.OnFieldChanged allow you to do?

4. Why does binding EditForm's Model to a record with init-only properties break two-way binding?

5. What CSS classes does Blazor automatically apply to built-in input components?

Was this page helpful?

Navigation and NavigationManager

Data Annotations Validation

Related Study Notes in Microsoft Technologies

Browse all study notes

Microsoft Technologies

Windows 10 / UWP Development Study Notes

.NET · 30 topics

Microsoft Technologies

Windows Batch Scripting Study Notes

Batch · 30 topics

Microsoft Technologies

MFC (Microsoft Foundation Classes) Study Notes

C++ · 30 topics

Microsoft Technologies

Silverlight Study Notes

.NET · 30 topics

Microsoft Technologies

XAML Study Notes

.NET · 30 topics

Microsoft Technologies

WPF (Windows Presentation Foundation) Study Notes

.NET · 30 topics

Topics covered

#BlazorStudyNotes#MicrosoftTechnologies#FormsAndEditForm#Forms#EditForm#Built#Input#StudyNotes#SkillVeris#ExamPrep

Forms and EditForm