Blazor-Interaktivität in .NET 9 und .NET 10: Eine vollständige Anleitung
Wenn Sie in den letzten Jahren Webanwendungen mit Blazor erstellt haben, wissen Sie, dass das Framework einen langen Weg zurückgelegt hat. Was als Wahl zwischen Blazor Server und Blazor WebAssembly begann, hat sich zu einem einheitlichen, flexiblen Rendering-Modell entwickelt, mit dem Sie für jede Komponente Ihrer Anwendung die richtige Interaktivitätsstrategie auswählen können.
Mit .NET 8 haben wir den grundlegenden Wandel vollzogen – die Einführung von Rendermodi und statischem serverseitigem Rendering (SSR) als Standard. Jetzt bauen .NET 9 und .NET 10 auf dieser Grundlage mit Verbesserungen auf, die das Entwicklererlebnis reibungsloser und das Endbenutzererlebnis schneller machen.
In diesem Beitrag möchte ich Sie durch das gesamte Bild der Blazor-Interaktivität in ihrer heutigen Form führen: wie Rendermodi funktionieren, was Streaming-SSR mit sich bringt, wie verbesserte Navigation und Formularverarbeitung das Spiel verändern und was in den neuesten Versionen neu ist. Wenn Sie ein neues Blazor-Projekt planen oder über ein Upgrade nachdenken, ist dies der Leitfaden, den ich mir gewünscht habe, als ich anfing, mich mit all dem zu befassen.
Ein kurzer Blick zurück: Wie wir hierher kamen
Vor .NET 8 mussten Sie sich auf Projektebene auf ein Hostingmodell festlegen. Blazor Server bedeutete, dass alles über eine SignalR-Verbindung auf dem Server lief. Blazor WebAssembly bedeutete, dass alles im Browser lief. Bei jedem gab es Kompromisse, und diese zu vermischen war schmerzhaft.
.NET 8 hat das Spiel verändert, indem es eine einzige Projektvorlage – die Blazor Web App – eingeführt hat, die beide Modelle vereint. Das Schlüsselkonzept sind Rendermodi: Sie entscheiden pro Komponente, wie sie gerendert werden soll und wo Interaktivität stattfindet. Der Standardwert wurde zum statischen SSR, was bedeutet, dass Komponenten auf dem Server gerendert werden und einfaches HTML an den Browser senden – kein SignalR, kein WebAssembly, nur schnelles HTML.
.NET 9 hat diese Konzepte verfeinert, das Entwicklererlebnis verbessert und die Leistung optimiert. .NET 10 geht noch einen Schritt weiter und bietet eine bessere Handhabung von Wiederverbindungen, einen persistenten Komponentenstatus über alle Rendermodi hinweg und Verbesserungen bei der Bereitstellung des Blazor-Skripts selbst.
Lassen Sie uns alles aufschlüsseln.
Rendermodi in .NET 9
Das Herzstück des modernen Blazor ist das Konzept der Rendermodi. Es gibt vier Modi, die Sie kennen sollten:
1. Statisches SSR (Standard)
Wenn Sie eine neue Blazor-Web-App erstellen, werden Komponenten standardmäßig statisch auf dem Server gerendert. Der Server verarbeitet die Razor-Komponente, generiert HTML und sendet es an den Browser. Es gibt keine dauerhafte Verbindung, keine WebAssembly-Laufzeit – nur herkömmliche Anfrage/Antwort.
Dies ist perfekt für inhaltsintensive Seiten, Dashboards, die hauptsächlich Daten anzeigen, oder jede Seite, auf der Sie keine Echtzeitinteraktion benötigen.
@page "/products"
<h1>Our Products</h1>
@foreach (var product in products)
{
<div class="product-card">
<h3>@product.Name</h3>
<p>@product.Description</p>
<span class="price">@product.Price.ToString("C")</span>
</div>
}
@code {
private List<Product> products = new();
protected override async Task OnInitializedAsync()
{
products = await ProductService.GetAllAsync();
}
}
Diese Komponente rendert auf dem Server, erzeugt HTML und das war’s. Keine laufende Verbindung. Schnelles anfängliches Laden, ideal für SEO, minimale Serverressourcennutzung.
2. Interaktiver ServerWenn Sie Echtzeit-Interaktivität benötigen – etwa das Klicken auf Schaltflächen, die Verarbeitung von Benutzereingaben oder die dynamische Aktualisierung der Benutzeroberfläche – können Sie sich für den interaktiven Servermodus entscheiden. Dadurch wird eine SignalR-Verbindung zwischen dem Browser und dem Server hergestellt, und UI-Updates erfolgen über diese Verbindung.
@page "/counter"
@rendermode InteractiveServer
<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
Die @rendermode InteractiveServer-Direktive ist alles, was Sie brauchen. Die Komponente wird zunächst auf dem Server gerendert und dann wird eine SignalR-Verbindung hergestellt, um nachfolgende Interaktionen abzuwickeln. Ihre C#-Ereignishandler werden auf dem Server ausgeführt und die UI-Unterschiede werden an den Browser gesendet.
Wann sollte man es verwenden: Wenn Sie Interaktivität benötigen, benötigen Ihre Komponenten Zugriff auf serverseitige Ressourcen (Datenbanken, APIs, Dateisysteme) und Sie möchten einen schnellen anfänglichen Ladevorgang, ohne auf den Download von WebAssembly warten zu müssen.
3. Interaktive WebAssembly
Wenn Sie Interaktivität wünschen, ohne eine Serververbindung aufrechtzuerhalten, führt Interactive WebAssembly Ihre Komponentenlogik mithilfe der .NET WebAssembly-Laufzeitumgebung direkt im Browser aus.
@page "/search"
@rendermode InteractiveWebAssembly
<h1>Product Search</h1>
<input @bind="searchTerm" @bind:event="oninput" placeholder="Search products..." />
@if (filteredProducts.Any())
{
<ul>
@foreach (var product in filteredProducts)
{
<li>@product.Name — @product.Price.ToString("C")</li>
}
</ul>
}
@code {
private string searchTerm = string.Empty;
private List<Product> allProducts = new();
private IEnumerable<Product> filteredProducts => allProducts
.Where(p => p.Name.Contains(searchTerm, StringComparison.OrdinalIgnoreCase));
protected override async Task OnInitializedAsync()
{
allProducts = await Http.GetFromJsonAsync<List<Product>>("api/products") ?? new();
}
}
Der Nachteil: Es fallen anfängliche Downloadkosten für die .NET-Laufzeitumgebung und Ihre Assemblys an. Aber sobald sie geladen ist, läuft die Komponente vollständig im Browser, ohne Server-Roundtrips für UI-Interaktionen.
Wann sollte man es verwenden: Für hochgradig interaktive Komponenten, bei denen die Latenz wichtig ist (denken Sie an Rich-Text-Editoren, Zeichentools, Echtzeitfilterung), wenn Sie die Serverlast reduzieren möchten oder wenn Sie eine progressive Web-App (PWA) erstellen.
4. Interaktives Auto
Das ist der pragmatische Mittelweg und eines meiner Lieblingsfeatures. Interactive Auto beginnt mit dem serverseitigen Rendering über SignalR für den ersten Ladevorgang und lädt dann stillschweigend die WebAssembly-Laufzeit im Hintergrund herunter. Bei späteren Besuchen wird die Komponente auf WebAssembly ausgeführt.
@page "/dashboard"
@rendermode InteractiveAuto
<h1>Dashboard</h1>
<DashboardWidget Title="Sales" Value="@salesTotal" />
<DashboardWidget Title="Users" Value="@activeUsers" />
<button @onclick="RefreshData">Refresh</button>
@code {
private decimal salesTotal;
private int activeUsers;
protected override async Task OnInitializedAsync()
{
await RefreshData();
}
private async Task RefreshData()
{
var data = await DashboardService.GetSummaryAsync();
salesTotal = data.SalesTotal;
activeUsers = data.ActiveUsers;
}
}
Dies bietet Ihnen das Beste aus beiden Welten: schnelles erstes Rendern (kein Warten auf den WASM-Download) und schließlich wird die Komponente clientseitig ausgeführt. Der Benutzer bemerkt den Übergang nicht.
Wann sollte man es verwenden: Wenn Sie sowohl schnelle anfängliche Ladevorgänge als auch eine eventuelle clientseitige Ausführung wünschen. Es ist eine großartige Standardauswahl für viele interaktive Komponenten.
Streaming SSR: Das Beste aus beiden Welten
Streaming SSR ist eine dieser Funktionen, die einfach klingt, aber einen enormen Unterschied in der wahrgenommenen Leistung macht. Hier ist die Idee: Anstatt darauf zu warten, dass alle Ihre Daten geladen sind, bevor HTML gesendet wird, sendet der Server die Seiten-Shell sofort und streamt Inhaltsaktualisierungen, sobald Daten verfügbar sind.
@page "/reports"
@attribute [StreamRendering]
<h1>Monthly Reports</h1>
@if (reports is null)
{
<div class="loading-spinner">
<p>Loading reports...</p>
</div>
}
else
{
<table class="table">
<thead>
<tr>
<th>Month</th>
<th>Revenue</th>
<th>Growth</th>
</tr>
</thead>
<tbody>
@foreach (var report in reports)
{
<tr>
<td>@report.Month</td>
<td>@report.Revenue.ToString("C")</td>
<td class="@(report.Growth >= 0 ? "text-success" : "text-danger")">
@report.Growth.ToString("P1")
</td>
</tr>
}
</tbody>
</table>
}
@code {
private List<MonthlyReport>? reports;
protected override async Task OnInitializedAsync()
{
// This might take a couple of seconds
reports = await ReportService.GetMonthlyReportsAsync();
}
}
Mit dem Attribut [StreamRendering] passiert Folgendes:
- Der Server sendet den HTML-Code sofort mit dem Loading Spinner.
OnInitializedAsyncwird ausgeführt und ruft die Daten ab.- Wenn die Daten eintreffen, streamt der Server den aktualisierten HTML-Code (die Tabelle) an den Browser.
- Der Browser patcht das DOM, ohne dass die gesamte Seite neu geladen werden muss.
Der Benutzer sieht die Seite sofort mit einer Ladeanzeige, dann wird der Inhalt ausgefüllt. Kein JavaScript-Framework erforderlich. Keine WebSocket-Verbindung. Einfach cleverer Einsatz von HTTP-Streaming.Verwendungszweck: Jede statische SSR-Seite, die beim Rendern Daten abruft. Produktlistenseiten, Dashboards, Berichte – überall dort, wo das anfängliche Laden der Daten mehr als ein paar hundert Millisekunden dauern kann.
Wann sollte man es NICHT verwenden: Wenn die Daten extrem schnell geladen werden (unter 100 ms), lohnt sich der Streaming-Overhead nicht. Außerdem bietet Ihnen das Streaming von SSR keine kontinuierliche Interaktivität – dafür benötigen Sie immer noch einen interaktiven Rendermodus.
Verbesserte Navigation und Formularverarbeitung
Eine der subtilen, aber wirkungsvollen Verbesserungen im modernen Blazor ist die verbesserte Navigation. Standardmäßig fängt Blazor interne Linkklicks und Formularübermittlungen ab, ruft den neuen Seiteninhalt über fetch ab und patcht das DOM, anstatt eine vollständige Browsernavigation durchzuführen.
Das bedeutet, dass sich das Navigieren zwischen statischen SSR-Seiten wie ein SPA anfühlt – kein ganzer Seiten-Flash, die Scroll-Position kann beibehalten werden und das Erlebnis ist seidenweich.
Wie es funktioniert
Wenn das Blazor-Skript (blazor.web.js) geladen wird, fängt es automatisch Klicks auf interne Links ab. Anstelle einer herkömmlichen Browser-Navigation:
- Stellt eine
fetch-Anfrage an die Ziel-URL. - Empfängt die HTML-Antwort.
- Führt den neuen Inhalt in das vorhandene DOM ein.
- Aktualisiert die URL und den Verlauf des Browsers.
Sie müssen nichts tun, um dies zu aktivieren – es ist standardmäßig aktiviert. Aber Sie können es kontrollieren:
<!-- Disable enhanced navigation for a specific link -->
<a href="/legacy-page" data-enhance-nav="false">Legacy Page</a>
<!-- Force a full page reload for external-like behavior -->
<a href="/downloads/report.pdf" data-enhance-nav="false">Download Report</a>
Verbesserte Formularverarbeitung
Formulare werden gleich behandelt. Wenn Sie EditForm oder das Standardelement <form> mit der Formularverarbeitung von Blazor verwenden, werden Übermittlungen über fetch abgefangen und verarbeitet:
@page "/contact"
<EditForm Model="contactModel" OnValidSubmit="HandleSubmit" FormName="contact" Enhance>
<DataAnnotationsValidator />
<div class="mb-3">
<label for="name">Name</label>
<InputText id="name" @bind-Value="contactModel.Name" class="form-control" />
<ValidationMessage For="() => contactModel.Name" />
</div>
<div class="mb-3">
<label for="email">Email</label>
<InputText id="email" @bind-Value="contactModel.Email" class="form-control" />
<ValidationMessage For="() => contactModel.Email" />
</div>
<div class="mb-3">
<label for="message">Message</label>
<InputTextArea id="message" @bind-Value="contactModel.Message" class="form-control" />
<ValidationMessage For="() => contactModel.Message" />
</div>
<button type="submit" class="btn btn-primary">Send</button>
</EditForm>
@code {
[SupplyParameterFromForm]
private ContactModel contactModel { get; set; } = new();
private async Task HandleSubmit()
{
await ContactService.SubmitAsync(contactModel);
contactModel = new ContactModel();
}
}
Das Enhance-Attribut auf EditForm weist Blazor an, die Formularübermittlung abzufangen. Das Formular wird an den Server gesendet, der Server verarbeitet es und rendert die Seite erneut, und der aktualisierte HTML-Code wird zurückgestreamt – alles ohne eine vollständige Seitennavigation. Es fühlt sich interaktiv an, ist aber vollständig vom Server gerendert.
Beachten Sie das Attribut [SupplyParameterFromForm] – auf diese Weise bindet Blazor gepostete Formulardaten in statischen SSR-Szenarien an Ihr Modell. Es ist die Brücke zwischen traditionellen Formpfosten und dem Komponentenmodell von Blazor.
Interaktivität pro Seite und pro Komponente
Einer der leistungsstärksten Aspekte des neuen Modells besteht darin, dass Sie Rendermodi innerhalb einer einzigen Anwendung mischen können. Ihre Produktlistenseite kann ein statisches SSR sein, Ihr Warenkorb kann ein interaktiver Server sein und Ihr Produktkonfigurator kann ein interaktiver WebAssembly sein – alles in derselben App.
Rendermodi auf Komponentenebene festlegen
Mit der Direktive @rendermode können Sie den Rendermodus direkt für eine Komponente festlegen:
@* This component is interactive via Server *@
@rendermode InteractiveServer
<h3>Live Chat</h3>
<!-- chat UI here -->
Oder Sie können es festlegen, wenn Sie eine Komponente von einem übergeordneten Element verwenden:
@page "/product/{Id:int}"
<h1>@product?.Name</h1>
<p>@product?.Description</p>
<!-- This child component gets its own interactive render mode -->
<ProductConfigurator Product="product" @rendermode="InteractiveWebAssembly" />
<!-- This stays static -->
<ProductReviews ProductId="Id" />
@code {
[Parameter] public int Id { get; set; }
private Product? product;
protected override async Task OnInitializedAsync()
{
product = await ProductService.GetByIdAsync(Id);
}
}
In diesem Beispiel ist die Seite selbst ein statisches SSR. Die Komponente ProductConfigurator wird auf WebAssembly ausgeführt und sorgt für umfassende clientseitige Interaktivität. Die Komponente ProductReviews bleibt statisch, da sie nur Daten anzeigt.
Rendermodi global festlegen
Wenn Sie möchten, dass alle Seiten standardmäßig interaktiv sind, können Sie den Rendermodus auf der Stammebene in App.razor festlegen:
<Routes @rendermode="InteractiveServer" />
```Dadurch wird jede Seite über das Server-Rendering interaktiv. Einzelne Komponenten können dies bei Bedarf immer noch überschreiben.
### Wichtige Regeln, die Sie beachten sollten
Beim Mischen von Rendermodi sind einige Einschränkungen zu beachten:
- **Eine untergeordnete Komponente kann keinen „interaktiveren“ Rendermodus als ihre übergeordnete Komponente haben.** Wenn eine übergeordnete Komponente statisch ist, können untergeordnete Komponenten statisch oder interaktiv sein. Wenn ein übergeordnetes Element jedoch ein interaktiver Server ist, kann ein untergeordnetes Element kein interaktives WebAssembly sein (es müsste ein Server oder ein automatischer Server sein).
- **Interaktive Komponenten können bereichsbezogene Dienste von statischen übergeordneten Komponenten nicht direkt nutzen.** Wenn eine Komponente auf WebAssembly ausgeführt wird, kann sie nicht direkt auf serverseitige `DbContext`-Instanzen zugreifen – Sie benötigen eine API-Ebene.
- **Der Status wird nicht automatisch zwischen den Rendermodi übertragen.** Wenn eine Komponente auf dem Server vorgerendert wird und dann zu WebAssembly wechselt, müssen Sie die Statuspersistenz explizit behandeln – mehr dazu im Abschnitt .NET 10.
## Was ist neu in .NET 10?
.NET 10 setzt den Ansatz der inkrementellen Verbesserung fort und konzentriert sich auf Zuverlässigkeit und Entwicklererfahrung. Hier sind die Highlights für die Blazor-Interaktivität:
### Verbessertes Wiederverbindungserlebnis
Wenn Sie den Interactive Server-Modus in der Produktion verwendet haben, sind Sie wahrscheinlich auf das Overlay für die erneute Verbindung gestoßen – den Moment, in dem die SignalR-Verbindung unterbrochen wird und dem Benutzer die Meldung „Verbindung wird wiederhergestellt …“ angezeigt wird. In .NET 10 wird dieses Erlebnis deutlich besser.
Die Wiederverbindungslogik ist jetzt intelligenter bei Wiederholungsversuchen. Anstelle eines festen Wiederholungsintervalls wird eine Backoff-Strategie verwendet, die sich der Situation anpasst. Die Benutzeroberfläche während der erneuten Verbindung ist ebenfalls ausgefeilter und Sie haben bessere Hooks, um das Erlebnis anzupassen:
```razor
<!-- In your App.razor or layout -->
<div id="components-reconnect-modal">
<div class="reconnect-visible">
<p>Connection lost. Attempting to reconnect...</p>
<div class="spinner"></div>
</div>
<div class="reconnect-failed">
<p>Could not reconnect to the server.</p>
<button onclick="location.reload()">Reload</button>
</div>
<div class="reconnect-rejected">
<p>Your session has expired.</p>
<a href="/">Return to Home</a>
</div>
</div>
Das Framework versucht jetzt auch aggressiver, die Verbindung bei vorübergehenden Ausfällen wiederherzustellen, und kann den Schaltkreisstatus zuverlässiger wiederherstellen. Dies bedeutet für Ihre Benutzer weniger „Bitte laden Sie die Seite neu“-Momente.
Persistenter Komponentenstatus über alle Rendermodi hinweg
Das ist eine große Sache. Wenn in .NET 9 eine Komponente auf dem Server vorgerendert wird und dann zu WebAssembly wechselt (oder zwischen den Rendermodi wechselt), geht der Komponentenstatus verloren. Die Komponente wird effektiv neu initialisiert, was zu doppelten Datenabrufen und einer flackernden Benutzeroberfläche führen kann.
.NET 10 verbessert den PersistentComponentState-Dienst, um bei Übergängen im Rendermodus reibungsloser zu funktionieren:
@page "/weather"
@rendermode InteractiveWebAssembly
@inject PersistentComponentState ApplicationState
<h1>Weather Forecast</h1>
@if (forecasts is null)
{
<p>Loading...</p>
}
else
{
@foreach (var forecast in forecasts)
{
<div class="forecast-card">
<h4>@forecast.Date.ToShortDateString()</h4>
<p>@forecast.Summary — @forecast.TemperatureC°C</p>
</div>
}
}
@code {
private List<WeatherForecast>? forecasts;
private PersistingComponentStateSubscription persistingSubscription;
protected override async Task OnInitializedAsync()
{
persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);
if (!ApplicationState.TryTakeFromJson<List<WeatherForecast>>(
"weather-forecasts", out var restored))
{
// Data wasn't persisted from prerendering — fetch it
forecasts = await Http.GetFromJsonAsync<List<WeatherForecast>>("api/weather");
}
else
{
forecasts = restored;
}
}
private Task PersistData()
{
ApplicationState.PersistAsJson("weather-forecasts", forecasts);
return Task.CompletedTask;
}
public void Dispose()
{
persistingSubscription.Dispose();
}
}
Mit den Verbesserungen in .NET 10 funktioniert dieses Muster zuverlässiger. Der während des Vorrenderns serialisierte Status ist ordnungsgemäß verfügbar, wenn die Komponente im interaktiven Modus initialisiert wird, wodurch doppelte Datenabrufe und das kurze Flackern vermieden werden, das Benutzer möglicherweise sehen.
Blazor-Skript als statisches Web-Asset
In früheren Versionen wurde die Blazor-JavaScript-Datei (blazor.web.js) vom internen Endpunkt des Frameworks bereitgestellt. In .NET 10 wird es als statisches Web-Asset bereitgestellt. Das mag nach einer kleinen Änderung klingen, hat aber praktische Vorteile:- Besseres Caching: Statische Web-Assets erhalten die richtigen Cache-Header und Fingerabdruck-URLs, sodass Browser sie effektiver zwischenspeichern können.
- CDN-freundlich: Da es sich um eine reguläre statische Datei handelt, können CDNs sie zwischenspeichern und von Edge-Standorten aus bereitstellen.
- Komprimierung: Die statische Web-Asset-Komprimierung wird automatisch angewendet, wodurch die Skriptgröße auf der Leitung reduziert wird.
Sie müssen die Art und Weise, wie Sie darauf verweisen, nicht ändern – das Framework verarbeitet den aktualisierten Pfad automatisch.
Best Practices: Auswahl des richtigen Rendermodus
Nachdem ich in mehreren Projekten mit all diesen Modi gearbeitet habe, ist hier mein Entscheidungsrahmen:
Beginnen Sie mit statischem SSR
Machen Sie statisches SSR zu Ihrem Standard. Auf den meisten Seiten in den meisten Anwendungen geht es hauptsächlich um die Anzeige von Daten. Produktseiten, Blogbeiträge, Benutzerprofile, Einstellungsseiten – diese erfordern keine Echtzeit-Interaktivität. Statisches SSR bietet Ihnen die beste Leistung, den geringsten Ressourcenverbrauch und das einfachste mentale Modell.
Fügen Sie Interaktivität nur bei Bedarf hinzu
Identifizieren Sie die spezifischen Komponenten, die in Echtzeit auf Benutzerinteraktionen reagieren müssen. Ein „Gefällt mir“-Button, ein Chat-Widget, eine Drag-and-Drop-Oberfläche – all das braucht Interaktivität. Aber die Seite um sie herum wahrscheinlich nicht.
Verwenden Sie Interactive Auto als interaktiven Go-To-Modus
Wenn Sie Interaktivität benötigen, ist Interactive Auto oft die beste Standardwahl. Es ermöglicht Ihnen schnelle anfängliche Ladevorgänge (Server-Rendering) mit anschließender clientseitiger Ausführung (WebAssembly). Der Benutzer erhält das Beste aus beiden Welten und Sie schreiben Ihren Code nur einmal.
Reservieren Sie den interaktiven Server für bestimmte Fälle
Verwenden Sie Interactive Server, wenn:
- Ihre Komponente benötigt direkten Zugriff auf Serverressourcen (Datenbanken, Dateisystem, interne APIs).
- Die Downloadgröße von WebAssembly ist ein Problem und Sie können Auto nicht verwenden.
- Aus Sicherheitsgründen (z. B. Verarbeitung sensibler Daten) muss die Komponente immer auf dem Server laufen.
Nutzen Sie Streaming SSR großzügig
Wenn Ihre statischen SSR-Seiten Daten abrufen, fügen Sie [StreamRendering] hinzu. Die Kosten sind minimal und die wahrgenommene Leistungsverbesserung ist erheblich. Benutzer sehen, dass Inhalte nach und nach angezeigt werden, anstatt auf eine leere Seite zu starren.
Behandeln Sie Zustandsübergänge sorgfältig
Wenn Sie Interactive Auto verwenden oder Pre-Rendering mit WebAssembly mischen, verwenden Sie immer PersistentComponentState, um doppelte Datenabrufe zu vermeiden. Ihre Nutzer werden es Ihnen danken, dass es keine flimmernden Inhalte gibt.
Behalten Sie den Komponentenbaum im Hinterkopf
Beachten Sie die Hierarchieregeln für den Rendermodus. Planen Sie Ihren Komponentenbaum so, dass interaktive Grenzen sinnvoll sind. Ein gängiges Muster ist ein statisches Layout mit eingebetteten interaktiven „Inseln“, wo nötig:
@* Layout: Static SSR *@
<header>
<NavMenu />
<UserMenu @rendermode="InteractiveServer" /> @* Needs real-time auth state *@
</header>
<main>
@Body
</main>
<footer>
<ChatWidget @rendermode="InteractiveAuto" /> @* Rich interactivity *@
</footer>
Fazit
Das Interaktivitätsmodell von Blazor in .NET 9 und .NET 10 stellt einen ausgereiften, durchdachten Ansatz zum Erstellen von Webanwendungen dar. Die Möglichkeit, Rendermodi pro Komponente auszuwählen, die nahtlose erweiterte Navigation, Streaming-SSR und die kontinuierlichen Verbesserungen bei der Wiederverbindung und der Zustandsverwaltung machen es zu einer überzeugenden Wahl für eine Vielzahl von Anwendungen.Die wichtigste Erkenntnis ist, dass Interaktivität ein Spektrum und keine binäre Wahl ist. Der Großteil Ihrer Bewerbung kann statisch sein. Einige Teile erfordern servergesteuerte Interaktivität. Einige könnten von der Ausführung im Browser profitieren. Blazor ermöglicht es Ihnen jetzt, diese Wahl mit der feinsten Granularität – der einzelnen Komponente – zu treffen, ohne das Framework zu bekämpfen.
Wenn Sie ein neues Projekt starten, ist mein Rat einfach: Erstellen Sie eine Blazor-Web-App, beginnen Sie mit statischem SSR, fügen Sie [StreamRendering] zu datenintensiven Seiten hinzu und befördern Sie einzelne Komponenten nur dann in interaktive Modi, wenn Sie sie benötigen. Am Ende erhalten Sie eine Anwendung, die schnell, effizient und gut skalierbar ist.
Viel Spaß beim Codieren. Wenn Sie Fragen haben, können Sie sich wie immer jederzeit an uns wenden!