Forms med EditForm

Læringsmål

• Opbygge forms med EditForm, OnValidSubmit og input-komponenter.
• Validere med DataAnnotations og vise fejl med ValidationMessage.
• Skelne mellem model-klasse og EditContext til avanceret validering.
• Forhindre submit når data er ugyldige (min længde, required).

Hvornår EditForm? Når brugeren indsender data I vil validere før HTTP — søgning, opret favorit, indtast API-nøgle-label — så I undgår unødige 400/404 mod OpgaverAPI.

I Blazor samler I formularer med <EditForm>. Den kræver en model og callbacks som OnValidSubmit / OnInvalidSubmit. Det tvinger jer til tydelige typer — godt når I senere mapper til API-DTO’er.

@page "/soeg-pokemon"
@using System.ComponentModel.DataAnnotations
@inject IPokemonService Pokemon

<EditForm Model="form" OnValidSubmit="HandleValidSubmit" OnInvalidSubmit="OnBad">
  <DataAnnotationsValidator />
  <ValidationSummary />

  <div class="mb-3">
    <label for="q">Navn</label>
    <InputText id="q" class="form-control" @bind-Value="form.Query" />
    <ValidationMessage For="@(() => form.Query)" />
  </div>

  <button type="submit" class="btn primary">Hent fra API</button>
</EditForm>

@if (results?.Count > 0)
{
  <ul>@foreach (var p in results) { <li>@p.Name</li> }</ul>
}

@code {
  private SearchForm form = new();
  List<PokemonDto>? results;

  private async Task HandleValidSubmit()
  {
    results = await Pokemon.SearchByNameAsync(form.Query);
  }

  private void OnBad() => results = null;

  public class SearchForm
  {
    [Required(ErrorMessage = "Navn er påkrævet")]
    [MinLength(2, ErrorMessage = "Mindst 2 tegn")]
    public string Query { get; set; } = "";
  }
}

DataAnnotations

Attributter på properties: [Required], [MinLength], [Range], [EmailAddress], [RegularExpression]. DataAnnotationsValidator kobler dem til EditContext.

public class ApiKeyForm
{
  [Required, StringLength(64, MinimumLength = 8)]
  public string KeyLabel { get; set; } = "";
}

Hvornår hvilken annotation? [Required] på tom submit. [MinLength] på søgestrenge. [Range] på limit i pagineret Pokémon-hentning. Server-side validering på API erstatter ikke client UX — begge lag er ideelle.

ValidationMessage vs Summary

• ValidationMessage For="..." — felt-specifik fejl ved input
• ValidationSummary — liste øverst i form

Hvornår ValidationMessage For=? Altid ved felt med brugerinput — For="@(() => form.Query)" binder fejl til netop det input. Summary alene skjuler hvilket felt der fejler i lange LoL-formularer.

<ValidationMessage For="@(() => form.ChampionName)" class="text-danger" />

EditContext (avanceret)

Når I skal validere på tværs af felter (fx «slutdato efter startdato»), opret I EditContext manuelt og lytter på OnValidationRequested.

var editContext = new EditContext(model);
<EditForm EditContext="editContext" OnValidSubmit="Submit">
  ...
</EditForm>

Hvornår manuel EditContext? Custom validators, «bekræft sletning» checkbox der påvirker hele form, eller dynamiske felter. Standard EditForm + Model dækker 80 % af skoleprojekter.

Model vs API-DTO

Form-model behøver ikke matche JSON 1:1. Map i OnValidSubmit til det DTO I sender med POST — fx opret favorit-Pokémon med kun name og id.

private async Task HandleValidSubmit()
{
    var dto = new CreateFavoriteDto(form.ChampionName.Trim(), form.Region);
    await Lol.PostFavoriteAsync(dto); // API-DTO kan have andre navne end form-klassen
}

Hvorfor det betyder noget: EditForm + annotations giver samme validering i UI og API — vigtigt ved POST til OpgaverAPI.

Baseret på MAGS Blazor-wiki og Microsoft Learn — Blazor.