Læringsmål
- Definere Blazor som komponentbaseret UI med C# og forklare SPA-idéen.
- Sammenligne Blazor Server, WASM og Hybrid på load, sikkerhed og offline.
- Beskrive hvordan UI (uanset hosting) kalder REST API over HTTP.
- Vælge render mode/interactivity bevidst i undervisningsprojekter.
Hvornår vælge Blazor? Når I allerede arbejder i C#/.NET og vil dele logik med API-projekter — typisk GUI + OpgaverAPI i samme klasseforløb.
Tjek dig selv før du går videre
- Du kan skelne UI-sync (SignalR) fra REST-kald til OpgaverAPI.
- Du kan nævne én fordel og én ulempe ved Blazor Server.
- Du har afspillet hosting-animationen (Server vs WASM).
Blazor er Microsofts moderne web-UI-stack: du bygger genbrugelige Razor-komponenter med C#, HTML og CSS. Udvikleroplevelsen minder om React, Svelte og Vue — komponent-tænkning, state, routing — men runtime-sproget er .NET i stedet for JavaScript.
Et Razor-komponent blander markup og C# i samme fil (.razor). Det gør det nemt at opdele UI i små dele: et Pokémon-kort, en LoL-champion-række, en søgebar — og lade dem dele services der kalder OpgaverAPI.
SPA og API — to lag
Selv om Blazor «føles» som én app, er data næsten altid HTTP JSON mod et backend API. Browseren (eller server-circuit) kører UI; HttpClient henter Pokémon-listen — samme model som katalogets demos.
Client ↔ Server over HTTP
Tryk Afspil — se request flyve til serveren og response tilbage. Skift scenarie for GET, POST eller 401.
# Vælg scenarie og tryk Afspil
I undervisningen bruger vi typisk Blazor Web App med interaktiv Server-render. WASM og Hybrid er vigtige at kende, så I kan vælge den rigtige model til eksamen og drift.
Trin i Network når I debugger: identificér om GET til OpgaverAPI kommer fra browser (WASM) eller server (Blazor Server HttpClient) — initiator-kolonnen og timing adskiller dem.
Tre hosting-modeller
Hvor kører koden?
Skift mellem Server og WASM — prikkerne viser trafikretning i realtid.
Blazor Server
Komponenter kører på serveren. UI-events og opdateringer går over en SignalR-forbindelse (WebSocket eller long polling). Fordele: lille første download, fuld .NET på serveren, nem debug i Visual Studio. Ulemper: latency ved hver interaktion, server skal holde circuit alive.
Blazor WebAssembly (WASM)
.NET runtime og jeres DLL’er downloades til browseren. Efter initial load kører event handlers lokalt. API-kald til OpgaverAPI er stadig almindelig HTTP — WASM ændrer ikke REST-kontrakten. Ulemper: større payload, forretningslogik er synlig, begrænset tråd-model.
Blazor Hybrid
Razor i native shell (MAUI, WPF med WebView). Relevant hvis I senere laver mobil/desktop — samme komponent-syntaks, anden distribution.
Render modes (.NET 8+)
Blazor Web App kan mixe static server render og interaktiv Server/WASM per komponent eller globalt. Undervisningsprojekter: vælg Interactive Server globalt indtil I har grund til WASM.
@rendermode InteractiveServer @* Eller i Program.cs: AddInteractiveServerRenderMode() *@
Hvornår Interactive WASM per komponent? Når én tung widget skal køre client-side uden at flytte hele appen — sjældent i første projekt. Start med global Server; skift kun med begrundelse i dokumentation.
Hurtig sammenligning
| Feature | Server | WASM | Hybrid |
|---|---|---|---|
| Lille første load | Ja | Nej | Nej |
| Offline efter download | Nej | Ja (UI; API kræver net) | Ja |
| Hemmelig logik på server | Ja | Nej | Delvist |
| Native device-API | Nej | Begrænset (browser) | Ja |
| Typisk hosting | ASP.NET + Docker | Static files / CDN | App store |
Relation til jQuery og «klassisk» web
I jQuery manipulerede I DOM direkte og kaldte $.ajax. I Blazor beskriver I hvordan UI skal se ud givet state; frameworket diff’er DOM. AJAX erstattes af HttpClient + async metoder — bedre struktur til større apps som et Pokémon-dex projekt.
Hvornår jQuery stadig nævnes? Kun som kontrast — undervisningsmål er komponent + DI + typed HTTP, ikke $('#list').html(...).
Faldgrube: At antage at «Blazor Server = ingen HTTP» — hver side der henter OpgaverAPI laver stadig HTTP fra server-processen. SignalR er kun UI-sync, ikke jeres REST-kald.
Quiz 1
Hvor kører Razor-komponentens C#-kode i Blazor Server?
Quiz 2
Hvilken hosting giver typisk mindst JavaScript/.NET-download ved første besøg?
Hvorfor det betyder noget: Valg af hosting påvirker latency når eleven klikker Pokémon — og hvor I debugger HttpClient.
Sådan fejler det i praksis: Tror SignalR erstatter HTTP til OpgaverAPI — Network viser stadig REST fra server eller browser.
Mini-opgave
Åbn Pokémon-demo og DevTools → Network. Identificér ét GET-kald til OpgaverAPI og notér URL, statuskode, og om kaldet stammer fra browser eller server-process (Blazor Server).
Quiz 3
Hentes Pokémon-JSON over SignalR i Blazor Server?
Læs hos Microsoft
Prøv med API
- Åbn endpoint-kataloget og se HTTP til flere backends — samme model jeres Blazor-app bruger via
HttpClient. - Sammenlign load-tid på demo-hub (statisk/Vite) med jeres egen Blazor-app — diskuter WASM vs Server.
Baseret på MAGS Blazor-wiki og Microsoft Learn — Blazor.