Blazor — interaktywny interfejs webowy w C#, bez JavaScriptu

Ten i kolejne 4 tematy to materiał DODATKOWY, wykraczający poza wymagania egzaminu zawodowego INF.04.7 — oficjalna podstawa programowa (INF.04.7.2) i informator CKE o egzaminie zawodowym wymieniają jako wymagane frameworki: ASP.NET Core, Django, Angular, React.js, Node.js — Blazora tam NIE MA. Ten blok jest przeznaczony dla osób, które opanowały już WSZYSTKIE poprzednie, wymagane lekcje tego działu (1-18) i chcą poznać nowocześniejsze, w pełni firmowane przez Microsoft podejście do budowy interaktywnych aplikacji webowych w C#, bez konieczności uczenia się JavaScriptu/TypeScriptu. Razor Pages i MVC (lekcje 3-8) renderują gotowy HTML na serwerze — każda interakcja użytkownika (kliknięcie, wysłanie formularza) to NOWE żądanie HTTP i przeładowanie fragmentu strony. Nowoczesne aplikacje webowe (jak popularny framework Angular) często działają inaczej — jako interaktywne komponenty aktualizujące się natychmiast, bez przeładowania strony. Blazor to WŁASNA odpowiedź Microsoftu na ten sam problem — pozwala pisać dokładnie taki interaktywny interfejs, ale w C#, w Visual Studio 2026, bez uczenia się drugiego języka programowania (JavaScript/TypeScript) i osobnego zestawu narzędzi (Node.js, npm).

Dlaczego Blazor, a nie Angular/React? Frameworki takie jak Angular czy React świetnie radzą sobie z budowaniem interaktywnych interfejsów, ale wymagają nauki JavaScriptu/TypeScriptu, osobnego środowiska (Node.js, npm, Angular CLI) i innego edytora przyzwyczajeń (choć technicznie da się je otworzyć w Visual Studio). Blazor daje DOKŁADNIE TĘ SAMĄ możliwość budowania komponentowego, interaktywnego interfejsu, ale w JĘZYKU C#, którego uczysz się od początku tego kursu (konsola, WPF, MAUI) — to trzeci (obok Razor Pages i MVC) sposób budowania interfejsu w ASP.NET Core, tym razem w pełni interaktywny, bez przeładowywania strony przy każdej akcji.

Dwa modele wykonania — Blazor Server i Blazor WebAssembly:

Model	Gdzie wykonuje się kod C#?	Zalety	Wady
Blazor Server	na SERWERZE — przeglądarka utrzymuje stałe połączenie (SignalR/WebSocket), wysyła zdarzenia (kliknięcia), odbiera instrukcje aktualizacji ekranu	szybki start, mały rozmiar pobierania, pełny, bezpośredni dostęp do bazy danych bez oddzielnego API	wymaga STAŁEGO połączenia z serwerem; niewielkie opóźnienie przy każdej interakcji
Blazor WebAssembly (WASM)	W PRZEGLĄDARCE — cały skompilowany kod .NET pobierany jest na start i działa lokalnie, jak prawdziwe SPA (podobnie do Angulara)	działa bez stałego połączenia z serwerem po pobraniu; natychmiastowa reakcja UI	większy plik pobierania na starcie; dostęp do bazy danych wymaga OSOBNEGO Web API (lekcja 20)

Ten kurs zaczyna od Blazor Server — prostszy model mentalny na start (mniej ruchomych części do zrozumienia naraz), ale WSZYSTKIE poznane tu komponenty i składnia .razor są niemal 1:1 przenoszalne do Blazor WebAssembly, gdybyś chciał później zbudować pełne SPA działające offline w przeglądarce.

Nowy, ujednolicony szablon "Blazor Web App" (Visual Studio 2026, .NET 8+) pozwala wybrać tryb interaktywności (None/Server/WebAssembly/Auto) osobno dla całej aplikacji ALBO per-strona/komponent przez dyrektywę @rendermode — to znaczy, że TA SAMA aplikacja może mieć część stron statycznych (szybkich, jak zwykłe Razor Pages) i część w pełni interaktywnych (Blazor), płynnie ze sobą współpracujących.

Anatomia komponentu Blazor (plik .razor). Jeden plik .razor łączy znaczniki HTML/Razor (widok) z blokiem @code { ... } zawierającym pola, właściwości i metody C# — to pojedynczy plik zamiast pary .cshtml/.cshtml.cs z Razor Pages (choć duże komponenty MOGĄ być podzielone na dwa pliki: Licznik.razor + Licznik.razor.cs, analogicznie do XAML+code-behind z WPF/MAUI). Kluczowe elementy: @page "/adres" (jeśli komponent ma być samodzielną, routowalną stroną), @rendermode InteractiveServer (włącza interaktywność), @onclick="MetodaCSharp" (podpięcie zdarzenia — bezpośredni odpowiednik Clicked="Metoda" z XAML w MAUI).