Blazor-Apps mit Fluent UI Blazor

Microsoft stellt seit einigen Jahren mit Blazor [1] ein Webframework als Open-Source-Software für die .NET-Plattform bereit. Mit Blazor programmieren Entwickler Web-Apps in C# (anstelle von JavaScript) mit HTML und CSS. ­HTML kommt für den Aufbau des User-Interface (UI), für dessen Struktur, das Layouting, die Auslösung von Events und das Data-Binding zum Einsatz. Das Styling des UI erfolgt mittels CSS über externe CSS-Dateien, Einbindung eines CSS-Frameworks oder durch direkte Einbettung von CSS-Anweisungen. Die seitens der Web-App benötigte UI- und Geschäftslogik implementiert der Entwickler mit der .NET-eigenen Programmiersprache C#.

Razor – komponentenorientiertes Templating mit C# und HTML/CSS

Bei der Bezeichnung Blazor handelt es sich um ein sogenanntes Kofferwort, das sich aus den drei Wörtern Browser, Client und Razor zusammensetzt. Eine Blazor-App besteht aus Komponenten, die ein Entwickler mittels der Template-Markup-Syntax von Razor spezifiziert. Für eine derartige Komponente hat sich die Bezeichnung Razor-Komponente eingebürgert. Ursprünglich zielte Microsoft mit Razor auf die Programmierung dynamischer Webseiten mit C# und VB.NET ab. Inzwischen gehört Razor als Bestandteil zum AspNetWebStack und ist als solcher eingebettet in das heutige ASP.NET Core.Über eine eigene Markup-Syntax integriert Razor HTML und C# – es handelt sich also um keine neue Programmiersprache! Beim Templating unterstützt Razor gängige Kon­strukte der imperativen Programmiersprache C#. So kennt Razor Fallunterscheidungen, Schleifen und Block-Bildung. Damit stehen dem Entwickler alle Sprachmittel der strukturierten Programmierung zur Verfügung. Die Kombination von HTML und C# in Razor-Templates führt zu einer optimierten Syntax für die HTML-Generierung. Die damit verbundene View-Engine mit der Bezeichnung Razor (CSHTML) verarbeitet das auf Code ausgerichtete Templating sehr effizient, da nur wenige Übergänge von HTML und C#-Code auftreten.Die Ablage der Spezifikation einer Komponente erfolgt in einer Datei mit der Erweiterung .razor. Dabei spielt Groß- und Kleinschreibung beim Namen einer Razor-Komponente keine Rolle. Es muss lediglich die Schreibweise des Namens der Komponentendatei mit dem Namen der Komponente übereinstimmen (wie sie die zugehörige Datei definiert). Um jedoch Blazor/Razor-Komponenten von anderen HTML-Elementen leichter zu unterscheiden, hat es sich eingebürgert, deren Namen immer mit einem Großbuchstaben zu beginnen. Eine Razor-Komponente ist grundsätzlich auf Wiederverwendung ausgerichtet: Sie kapselt die UI-Struktur (HMTL) und die zugehörige Logik (C#).Um Kollisionen beim Styling mit anderen Komponenten zu vermeiden, befinden sich die spezifischen CSS-Stile einer Razor-Komponente in einer *.razor.css-Datei. Dabei muss die Ablage der Razor-Komponente und der zu ihr gehörenden CSS-Style-Datei immer im selben Ordner erfolgen.Razor-Komponenten können aus anderen Razor-Komponenten zusammengesetzt werden. Damit baut der Entwickler schrittweise komplexe UIs auf. Um das Styling von einer Eltern-Komponente an eine Kind-Komponente weiterzureichen, kommt das ::deep-Pseudo-Element im CSS-Konstrukt der Eltern-Komponente zum Einsatz (Listing 1). Somit entfällt die Notwendigkeit, für die Kind-Komponente eine separate *.razor.css-Style-Datei anzulegen.

Einordnung von Fluent UI Blazor in die Welt der Webtechnologien

Ausgangsbasis für Fluent UI Blazor bilden die über FAST/Fluent bereitgestellten W3C-kompatiblen Webkomponenten. Diesen Standard des W3C für Webkomponenten unterstützt inzwischen jeder moderne Webbrowser. Alle gemäß dem W3C-Standard kompatiblen Komponenten lassen sich in der Programmierung wie normale HTML-Elemente verwenden (siehe den ersten Teil dieser Serie [2]). Damit arbeiten Webkomponenten interoperabel und modular miteinander – deshalb können Programmierer sie mit jedem beliebigen Framework kombinieren.Microsoft hat mit FAST [3] verschiedene Technologien entwickelt, die auf dem W3C-Standard der Webkomponenten basieren (Bild 1):

• FAST Element: Eine leichtgewichtige Library, die Entwickler für die Programmierung eigener Webkomponenten (gemäß dem W3C-Standard) einsetzen können. Die Programmierung mit FAST Element erfolgt in HTML/CSS und Java­Script/TypeScript. Microsoft stellt FAST Element als NPM-Library zur Verfügung: @microsoft/fast-element. Durch Erweiterung ihrer Klassen lassen sich eigene Webkomponenten definieren und über <tag>-Elemente für die Entwicklung von Web-Apps bereitstellen. Zusätzlich kann man die Library mit jedem beliebigen Frontend-Framework kombinieren, um FAST in ein anderes Framework oder Build-System zu integrieren.
• FAST Frame: Ein konfigurierbares Design-System (siehe [2]), das aus einer Menge von Webkomponenten und Design Tokens für die Deklaration eines Design-Systems besteht. Als NPM-Library stellt Microsoft die FAST Frame Design Tokens in @microsoft/fast-components zur Verfügung. Zusammen mit den in @microsoft/fast-foundation verfügbaren Klassen können UX-Designer ein eigenes Design-System basierend auf den FAST-Komponenten konzipieren. Mittels FAST Frame hat Microsoft sein eigenes Design-System Fluent für die Welt der Webentwicklung zugänglich gemacht.
• Web Components: Über die NPM-Library @microsoft/fast-components stehen W3C-kompatible HTML-Elemente zur Verfügung, die man nach Import und Registrierung über Wrapper in anderen Frameworks nutzen kann. Das FAST-Team bei Microsoft hat eine Vielzahl von Frameworks für die FAST Web Components erschlossen: Angular, ASP.NET, Aurelia, Blazor, Ember, React, Rollup, Svelte, Vite, Vue und Webpack. Gemäß dieser Vorgehensweise entwickelte ein Team bei Microsoft für das Blazor-Framework die Fluent UI Blazor Library.

Einrichten und Arbeiten mit einem .NET-Ökosystem

Voraussetzung für die Entwicklung mit Blazor und damit auch für Fluent UI Blazor stellt eine Installation des .NET SDK dar. Die Microsoft-Download-Seite unter [4] stellt für das gewünschte Betriebssystem (Linux, macOS, Windows) einen Release der aktuellen Version 8 zum Herunterladen bereit. Ein Klick auf den dortigen URL-Verweis All .NET versions zeigt alle anderen Releasestände an, für die Microsoft einen Support anbietet. Aus Stabilitätsgründen sollte in der Produktion nur eine LTS-Version (Long Term Support) eingesetzt werden. Nach dem Download erledigt das Ausführen der heruntergeladenen Datei direkt die Installation.Das Installationsprogramm richtet einen Eintrag in der Path-Umgebungsvariablen des Betriebssystems für das In­stallationsverzeichnis des .NET SDK ein. Der Terminalbefehl where dotnet zeigt dieses Installationsverzeichnis an. Für das Arbeiten in Projekten steht für das .NET SDK ein CLI (Command Line Interface) über dotnet zur Verfügung. Das über dotnet-Befehle erreichbare CLI enthält ein integriertes Hilfesystem, das der Befehl dotnet -h beziehungsweise dotnet --help anzeigt. Weitergehende Informationen zum Beispiel über den CLI-Befehl command liefert das Terminalkommando dotnet [command] --help. Das dotnet-CLI teilt seine Befehle in drei Gruppen ein: .NET-Anwendungen, .NET-SDK-Befehle und Toolpakete. Der Befehl dotnet --version gibt die aktuell aktivierte Versionsnummer des .NET SDK aus.Alle installierten SDK-Versionen listet der CLI-Befehl dotnet --list-sdks auf (Bild 2), während der Terminalbefehl dotnet --list-runtimes alle verfügbaren Runtimes anzeigt. Umfassende Informationen zur aktuell aktivierten .NET-Umgebung liefert der Befehl dotnet --info. Arbeitet der Programmierer in seinen Projekten mit verschiedenen .NET-SKD-Releases, so definiert das optionale Sdk-Attribut in der Projektdatei (.csproj), welches SDK (mit welchem Framework) und im Bedarfsfall welche Version verwendet werden soll. Die Datei global.json legt die Version des .NET SDK für die Ausführung von CLI-Befehlen fest (Listing 2). Grundsätzlich sucht das .NET SDK im aktuellen Arbeitsverzeichnis oder in einem übergeordneten Ordner des Projektverzeichnisses nach dieser global.json-Datei.

Für das Arbeiten in einer .NET-Entwicklungsumgebung sollte der Entwickler die SDK-Befehle add, list, sln und workload des dotnet-CLI kennen. Der SDK-Befehl add fügt einem Projekt ein NuGet-Package oder eine Projektreferenz hinzu. Der dotnet list-Befehl zeigt die in einem Projekt oder die in einer Projektmappe/Solution enthaltenen Package-Verweise beziehungsweise Projektverweise an. Der dotnet sln-Befehl dient der Neuanlage und der anschließenden Verwaltung einer Projektmappe/Solution.Mit dem list-Kommando gibt der dotnet sln-Befehl alle in einer Projektmappe enthaltenen Projekte aus; das remove-Kommando entfernt ein Projekt aus der Projektmappe. Um Workloads (optionale Komponenten des .NET SDK) zu installieren, installierte oder für .NET verfügbare Workloads anzuzeigen oder zu aktualisieren, kommen verschiedene Varianten des dotnet workload-Befehls zum Einsatz.

Mit Render-Modes gezielt Effizienz und ­Flexibilität einer Web-App steuern

Seit der Konzeption von Microsoft unterstützt Blazor zwei grundlegende Methoden für das Rendering: serverseitig (Blazor Server) und clientseitig (Blazor WebAssembly). Mit Version 8 von .NET hat das Blazor-Team diese beiden Methoden durch sogenannte Render-Modes verfeinert. Diese Render-Modes bieten dem Programmierer jetzt die Möglichkeit, das Rendering der Blazor-App zu steuern und anhand der geforderten Interaktivität zu optimieren:

• StaticServer: Dabei handelt es sich den Default-Render-­Mode für serverseitiges Blazor-Rendering. Ein statisches serverseitiges Rendering (statisches SSR) führt .NET auf dem Webserver aus. Zum Startzeitpunkt überträgt der Webserver die gerenderte App auf den Client. Dieser Modus eignet sich nur für Inhalte, die sich nicht ändern und keine Interaktivität seitens des Benutzers erfordern.
• InteractiveServer: Auch interaktives SSR genannt, erledigt das ASP.NET-Core-Laufzeitsystem auf dem Server. Die Blazor-Komponente führt der Server im interaktiven Modus aus – dabei verarbeitet der Server vollständig die Interak­tionen. Dieser Modus eignet sich für Komponenten, die auf Benutzerinteraktionen reagieren, deren dynamische Inhalte der Client vom Server anfordert und auf den Client überträgt. Die Kommunikation des Clients zum Server für die Razor-Komponente erfolgt effizient und performant über ­eine WebSocket-Verbindung mit SignalR in ASP.NET Core.
• InteractiveWebAssembly: Es findet clientseitiges Rendering (CSR) der Blazor-Komponente auf dem Client im Webbrowser mittels WebAssembly statt. Dieser Modus ist ideal für interaktive Benutzeroberflächen, die auf Benutzeraktionen sofort reagieren müssen. Die komplette App mit den Razor-Komponenten und die benötigte .NET Runtime überträgt der Server auf den Client; dieser führt die Web-App im Browser über die WebAssembly-basierte .NET-Laufzeitumgebung aus. Dies entspricht dem Standardmodus für clientseitiges Blazor-Rendern.
• InteractiveAuto: Anfangs kommt auf dem Server mittels ASP.NET Core interaktives SSR zum Einsatz; dabei erfolgt ein paralleler Download der gerenderten Inhalte auf den Client. Nach dem Download der Blazor-App verarbeitet der Client alle nachfolgenden Events und Interaktionen des Endbenutzers mittels CSR (Interactive WebAssembly). Dieser Modus kombiniert also SSR mit CSR und erweist sich als nützlich, um die Ladezeit zu optimieren und gleichzeitig Interaktivität zu bieten.

Weitere besondere Techniken für flexibles ­Rendering verfügbar

Grundsätzlich fällt bei CSR (Blazor WebAssembly) die Reaktions- respektive Latenzzeit geringer aus als beim SSR (Blazor Server) – allerdings auf Kosten einer höheren Startdauer der App. Im Fall von Blazor kommt beim CSR auf dem Client im Webbrowser WebAssembly (Wasm) zum Einsatz – wobei eine Integration von JavaScript mit Wasm möglich ist. Als zusätzliche Techniken für das Rendering unterstützt das Blazor-Framework Prerendering (Vorabrendern) und Streaming.Prerendering erzeugt für Teile einer Seite auf dem Server statisches HTML, bevor diese an den Client gesendet wird. Prerendering ist suchmaschinenfreundlich, da der erzeugte HTML-Code eine Search Engine Optimization (SEO) ermöglicht. Für ASP.NET Core stehen Prerendering-Features im Package Microsoft.AspNetCore.Server.SpaServices zur Verfügung. Die Technik des Streaming sendet schrittweise HTML-Inhalte an den Client, während sie generiert werden. Dies bewirkt beim Endbenutzer eine Verbesserung der Wahrnehmung, da er bereits Inhalte sieht, während ein verbleibender Rest der Seite noch geladen wird. Die Realisierung von Strea­ming erfolgt über SignalR von ASP.NET Core.Generell vererbt eine Razor-Komponente ihren Render-Mode an alle ihre Kinder. Innerhalb einer Hierarchie reicht eine Razor-Komponente ihren Render-Mode an alle beteiligten untergeordneten Komponenten weiter: Man nennt dies Render-Mode-Propagation. Mit Version 8 der .NET-Plattform hat Microsoft für eine Razor-Komponente eine neue @rendermode-Directive eingeführt. Darüber legt der Programmierer das Rendering für eine Razor-Komponente der Web-App gezielt durch Auswahl eines Render-Modes fest: InteractiveAuto, InteractiveServer und InteractiveWebAssembly.Die Deklaration des Render-Modes erfolgt entweder bei der Definition der Razor-Komponente im Quellcode (@rendermode InteractiveServer) oder bei der Instanzierung einer Komponenteninstanz anhand eines Parameters: <RazorKomponente @rendermode=”@RenderMode.InteractiveServer” />; was den Render-Modus für diese Komponenteninstanz überschreibt. Ein beliebiges Ändern des Render-Modes zur Laufzeit einer Komponente unterstützt das Blazor-Framework derzeit noch nicht.

Infrastruktur für die Programmierung von ­Blazor-Apps verfügbar machen

Als integrierte Entwicklungsumgebung (Integrated Development Environment / IDE) für Blazor eignen sich Visual Studio Code (VS Code) oder Visual Studio 2022. Für die Programmierung von Web-Apps stellt der Visual Studio Installer die Workload APS.NET und Webentwicklung (ASP.NET and web development) für Visual Studio zur Verfügung. Für den Einsatz von WebAssembly (Wasm) mit VS Code installiert der Befehl dotnet workload install wasm-tools die Blazor WebAssembly Build Tools in das vorhandene .NET-System. In der Work­load ASP.Net and web development von Visual Studio sind diese bereits enthalten. Für die Programmierung mit VS Code stellt das dotnet-CLI verschiedene Projekttemplates als Vorlagen über den new-Befehl bereit:

• blazor: Generiert als Blazor-Web-App-Projekt eine programmierte Beispielanwendung mit linkem Navigationsmenü, einer Webseite mit Schaltfläche als Klickzähler und einer Webseite mit einer Datenausgabe in einer Tabelle. Der Befehl dotnet new blazor -h zeigt alle für die Neuanlage verfügbaren Parameter an.
• blazorwasm: Erzeugt ein Blazor-WebAssembly-Standalone-App-Projekt, das die obige gängige Beispiel-App enthält. Der Programmierer erkundet mit dem dotnet-Hilfesystem dotnet new blazorwasm -h die für diesen Projekttyp verfügbaren Einstellmöglichkeiten. So erstellt zum Beispiel der Befehl bei Übergabe des Parameters -p beziehungsweise --pwa die Web-App als PWA (Progressive Web App).
• blazorserver: Erzeugt ein Blazor-Server-App-Projekt – eine Blazor-App mit serverseitigem Rendering und der oben erläuterten codierten Beispiel-App.
• blazorwasm-empty und blazorserver-empty: Diese beiden Projekttemplates erzeugen leere Apps, die keine Funktionalität in ihrem Bespielcode besitzen. Die Web-Apps sind auf WebAssembly beziehungsweise Server-Rendering ausgerichtet und geben lediglich ein „Hello, world!“ im Browser aus.

Zusätzlich empfiehlt es sich, in VS Code über den Marketplace der IDE die Erweiterung C# Dev Kit zu installieren. Dieses C# Dev Kit unterstützt das Arbeiten mit den Dateien im Projekt über einen Solution-Explorer ebenso wie das inte­grierte Debugging/Testen in der IDE und führt den Build/Run eines Projekts durch. Eine Installation des C# Dev Kits macht in VS Code auch die Erweiterungen C#, das .NET Install Tool und IntelliCode for C# Dev Kit verfügbar. Während die C#-Erweiterung und IntelliCode vor allem die Codierung von Quellcode mit C# erleichtern, hilft das .NET Install Tool beim Einrichten und Verwalten des .NET SDK und der .NET Runtimes. Für das Debugging im Browser benötigt dieser eine Installation der Dev Tools von Google.

Das Microsoft-Team stellt für Fluent UI Blazor spezielle Projektvorlagen bereit

Das Microsoft-Team für Fluent UI Blazor stellt über das NuGet-Repository im Web ein .NET-SDK-Package mit zwei Project Templates (Projektvorlagen) für die Programmierung mit dem .NET SDK in VS Code oder Visual Studio 2022 bereit. Seit Version 8 von .NET befinden sich die beiden Fluent-UI-Blazor-Templates in einem neuen NuGet-Package mit dem Namen Microsoft.FluentUI.AspNetCore.Templates.Der Name dieses neuen Packages soll im Unterschied zur alten Bezeichnung Microsoft.Fast.Components.FluentUI die Unabhängigkeit des Fluent-UI-Blazor-Teams vom FAST-Team und seine stärkere Verbundenheit mit der .NET-Technologie zum Ausdruck bringen. Um die im neuen NuGet-Package enthaltenen beiden Templates für die Neuanlage eines Projekts zu verwenden, müssen sie zuerst installiert werden. Die Installation des Fluent-UI-Blazor-Template-Packages erledigt der CLI-Befehl dotnet new install Microsoft.FluentUI.AspNetCore.Templates in einem Terminalfenster.Der Terminalbefehl dotnet new list fluentblazor überprüft, ob die im zuvor genannten NuGet-Package enthaltenen beiden Projektvorlagen (Kurzname: fluentblazorwasm, fluentblazor) in das .NET SDK installiert wurden (Bild 3). Um alle verfügbaren Versionen eines NuGet-Packages zu erkunden, geht man auf die Homepage von NuGet [5]. Nach Eingabe eines Suchstrings, zum Beispiel FluentUI.AspNetCore, im Eingabefeld Search for packages … und einem Klick auf das rechts stehende Icon-Symbol einer Lupe zeigt die NuGet-Homepage alle verfügbaren NuGet-Packages an, die diesen Namen enthalten. Ein Klick auf das gewünschte NuGet-Package mit „Template“ am Namensende öffnet dessen Eintrag auf der NuGet-Homepage.

Auf dieser Webseite des NuGet-Package-Eintrags gibt es vier Registerreiter: README, Dependencies, Used By und Versions. Ein Klick auf das Register Versions zeigt eine Liste aller Versionsnummern des angezeigten NuGet-Packages an. Um eine bestimmte Version aus dieser Liste zu installieren, führt man den CLI-Befehl dotnet new install <Package­Name>::<VersionsNummer> aus. Beispielsweise installiert der CLI-Befehl dotnet new install Microsoft.FluentUI.AspNetCore.Templates::4.3.1 die Version 4.3.1 der Fluent-UI-Blazor-Templates in das .NET SDK. Um dieses NuGet-Package wieder komplett aus dem .NET SDK zu entfernen, kommt der CLI-Befehl dotnet uninstall Microsoft.FluentUI.AspNetCore.Templates zum Einsatz.

Entwicklungsprojekt für eine Fluent-UI-Blazor-App mit Visual Studio anlegen

Mithilfe der beiden zuvor neu installierten Projektvorlagen erstellt der Programmierer in der IDE ein passendes Starterprojekt für Fluent UI Blazor. Nach dem Start von Visual Studio 2022 öffnet ein Klick auf die rechts unten stehende Kachel Neues Projekt erstellen (Create a new project) das gleichnamige Dialogfenster. Anschließend gibt der Entwickler im Eingabefeld Nach Vorlagen suchen (Search for templates) ([Alt] + [S]) die Zeichenkette Fluent UI Blazor ein. Danach zeigt Visual Studio 2022 in der rechten Liste unterhalb des Eingabefelds die folgenden beiden für Fluent-UI-Blazor-Projekte geeigneten Kacheln an:

• Eigenständige Fluent Blazor WebAssembly-App (Fluent Blazor WebAssembly Standalone App): Dabei handelt es sich um eine Projektvorlage, die eine Blazor-App mit Fluent-2-UI-Komponenten erstellt und die der Browser über WebAssembly ausführt. Die mit dieser Projektvorlage erzeugte App läuft ohne SSR als reine SPA (Single-Page-App) vollständig im Client. Neben verschiedenen Optionen für die Code-Generierung unterstützt diese Projektvorlage über eine Checkbox die Deklaration der App als PWA (Progressive Web-App).
• Fluent Blazor Web App: Diese Projektvorlage erzeugt eine Blazor-Web-App auf der Basis von Fluent 2 [6], die sowohl SSR als auch CSR (Client Interactivity) unterstützt. Daher gliedert sich diese App in zwei Bestandteile: einen Client- und einen Server-Teil. Dieses Template eignet sich besonders für Web-Apps mit umfangreichen dynamischen Benutzeroberflächen.

Nach Auswahl einer der beiden Projekttypen über die Kacheln und einem Klick auf die Schaltfläche Weiter / Next erscheint bei beiden das Dialogfenster Neues Projekt konfigurieren / Configure your new project. Dabei vergibt der Programmierer einen Projektnamen, benennt den Ablageort für das Projekt und spezifiziert weitere Eigenschaften zum Umfang des zu erzeugenden Quellcodes der neuen Fluent-UI-Blazor-App. Bei Auswahl der Checkbox Include sample pages generiert Visual Studio zusätzlich zur MainLayout- und Home-Seite zwei weitere Anzeigeseiten Counter.razor (Schaltfläche mit Klickzähler), Weather.razor (Datenausgabe von Temperaturen in Tabellenform) und zusätzlich eine Navigationsseite Nav­Menu.razor.

Auswahloptionen erzeugen spezielle Features für den Quellcode der App

Über die Authentication Type-Auswahlliste Individuelle Benutzerkonten / Individual User Accounts erzeugt Visual Studio den Quellcode für eine Benutzerauthentifizierung mithilfe von ASP.NET Identity. Bei Auswahl von Microsoft Identity Platform erstellt Visual Studio eine Anwendung, die Azure Active Directory (Azure AD) für die Authentifizierung verwendet. Eventuell startet Visual Studio einen Hintergrundprozess, um die für den ausgewählten Authentication Type notwendigen .NET-Komponenten nach Bestätigung durch den Programmierer zu installieren.Die Auswahl der Option Configure for HTTPS nimmt eine Konfiguration der Anwendung für das sichere HTTPS-Protokoll vor und aktiviert Core-Hosting, um eine ASP.NET-Core-Hosted-Anwendung zu erstellen. Eine App mit Core-Hosting ermöglicht eine bessere Skalierung, schnellere Ladezeiten, höhere Sicherheit und Offline-Verfügbarkeit. Für Core-Hosting bietet sich eine Dreiteilung der App in Client, Server und Shared an. Auf dem Client läuft die Blazor-WebAssembly-App, der Serverteil übernimmt die Geschäftslogik und Datenverwaltung, während der Shared-Teil die gemeinsamen Modelle und Ressourcen von Client und Server enthält. Diese Dreiteilung ermöglicht auch ein einfacheres Deployment auf verschiedene Hosting-Plattformen (zum Beispiel Azure, AWS oder Docker).Für den Projekttyp Fluent Blazor Web App legt die Auswahlliste Interactive render mode einen der oben beschriebenen Render-Modi fest. Die Auswahlliste Interactivity location bestimmt für den ausgewählten Render-Modus, ob er global für die gesamte App oder für jede Seite/Komponente separat greifen soll. Für eine Standalone-­Fluent-Blazor-Web­Assembly-App erzeugt die Checkbox Progressive Webanwendung die service-worker.js-Datei der PWA. Die für eine PWA in der Regel zusätzlich empfohlene manifest.json-Datei muss der Entwickler nachgelagert manuell anlegen.

Anlegen eines Starterprojekts mit Visual Studio Code (VS Code)

Im Unterschied zu reinen Blazor-Apps unterstützt die Command Palette von VS Code nicht wie bei anderen Projekt­typen üblich die Anlage eines neuen Fluent-UI-Blazor-Projekts. Kommt in der Entwicklung also nicht Visual Studio, sondern VS Code als IDE zum Einsatz, so stehen die neu konzipierten Projektvorlagen für Fluent UI Blazor nur über das in VS Code integrierte Terminalfenster mittels dotnet-CLI zur Verfügung. Für die Ablage der Dateien des Projekts richtet der Programmierer einen neuen Ordner ein und öffnet diesen in VS Code.Über das Terminal-Menü startet der Eintrag New Terminal ein neues Terminalfenster. Dort erzeugt der CLI-Befehl dotnet new fluentblazor -o <projektName> eine Fluent-Blazor-Web-App, während der CLI-Befehl dotnet new fluentblazorwasm -o <projektName> eine Fluent-Blazor-WebAssembly-Standalone-App anlegt. Zusätzlich gibt der dotnet new-Befehl eventuell durchzuführende Updates für die enthaltenen NuGet-Packages als Informationsmeldung aus. Diese sollten bei der Neuanlage eines Starterprojekts Berücksichtigung finden. Über zusätzliche Parameter legt der Programmierer weitere optionale Vorgaben für das Template fest. Im Fall einer Fluent-Blazor-Web­Assembly-Standalone-App erzeugt der Parameter -p beziehungsweise --pwa bei der Projektanlage gleich die benötigten Dateien für eine PWA (Progressive Web-App) mit.Für leichteres Arbeiten in einem Blazor-Projekt mit VS Code finden sich im Marketplace der IDE verschiedene Erweiterungen. So stellt Microsoft.AspNetCore.Razor.VSCode.BlazorWasmDebuggingExtension zusammen mit der C#-Extension für das Debugging der Blazor-App spezifische Wasm-Features zur Verfügung. Im Bedarfsfall muss diese Erweiterung in VS Code nachinstalliert werden. Um schnell und bequem zwischen den Razor-Komponenten (*.razor) und den eigenen Code-behind-Dateien (*.razor.cs) im Quellcode-Editor umzuschalten, erweist sich der ASP.NET Core Switcher als hilfreich. Von dieser Marketplace-Extension gibt es zwei Varianten, dabei sollte auf die optimierte Ausgabe von Adrian Wilczynski zurückgegriffen werden.

Ein Fluent-Blazor-Projekt besitzt einen ­strukturierten, systematischen Aufbau

Eine Fluent-Blazor-Web-App enthält in ihrem Client-Teil auf der Projektebene wie eine eigenständige Fluent-Blazor-WebAssembly-App (SPA) die beiden Ordner Layout und Pages. Im ersten Verzeichnis Layout befinden sich alle Razor-Komponenten, die für das Layouting zuständig sind. Die dortigen Dateien beschreiben die Struktur und das Erscheinungsbild der App. So enthält der Layout-Ordner die Hauptlayout-Komponente (MainLayout.razor), die das allgemeine Layout definiert; dazu gehören Header, genereller Seitenaufbau und Footer. Es empfiehlt sich, hier alle globalen Skripte und Ressourcen einzubinden, die auf den Seiten der App verfügbar sein sollen. Das Navigationsmenü der linken Seitenleiste implementiert NavMenu.razor.Der Header identifiziert das Benutzerkonto und umfasst den Namen der App sowie eventuell ein Logo des Unternehmens beziehungsweise dessen Marke/Branding. Der allgemeine Seitenaufbau referenziert die Navigationsleiste und beschreibt die weitere Aufteilung der Seite als FluentStack mit ChildContent und ErrorContent. Im ErrorContent gibt eine Blazor-WebAssembly-App Fehlerinformationen aus, wenn eine Seite nicht gefunden wird oder ein Serverfehler auftritt. Dazu erzeugt Blazor WebAssembly ein Exception-Objekt und zeigt die zugehörige Fehlermeldung über @ex.Message an. Im Unterschied dazu übernimmt das Fehlerhandling einer Blazor-Web-App auf dem Server eine eigenständige Error.razor-Komponente (Bild 4).

Der Footer kann Übersichtsinformationen wie Copyright, Angaben zum Datenschutz oder die Kontaktmöglichkeiten aufnehmen. Die Navigationsleiste enthält Links/Verweise zu den verschiedenen Seiten der Web-App als Menüeinträge, um das Routing abzubilden und die Navigation durchzuführen. Der Ordner Pages im Projektverzeichnis Components nimmt alle Razor-Komponenten auf, welche die Benutzeroberflächen der App deklarieren. Dabei handelt es sich im Wesentlichen um Razor-Komponenten, die Daten über die Oberflächen-Elemente anzeigen, neu anlegen oder ändern.Zusätzlich gibt es im Projekt noch weitere Razor-Dateien, die sich außerhalb der beiden Ordner Layout und Pages befinden: _Imports.razor, Routes.razor (nur bei einer Blazor-Web-App) und App.razor. Die Datei _Imports.razor importiert alle Razor-Komponenten und andere Ressourcen, die ein Entwickler für die Seiten der Web-App verwendet. Die Datei Routes.razor existiert nur in einer Blazor-Web-App, sie deklariert auf deren Client-Seite das Routing der App. Das Routing ordnet den URLs die entsprechenden Funktionen oder Seiten der App zu und realisiert die Navigation. Bei der Implemen­tierung des Routings greift eine Blazor-Web-App auf die in ASP.NET Core integrierte Routing-Engine zurück.Ein Programmierer kann auch eine alternative Routing-Bibliothek einbinden. Dies wirkt sich allerdings negativ aus, wenn zusätzlicher Aufwand etwa für das Prerendering anfällt. Die App.razor-Datei ist der zentrale Ablageort mit Informationen zur Konfiguration, der Spezifikation eines globalen Render-Modus und dem Bootstrapping des Blazor-Frameworks. Die dortigen Deklarationen beschreiben alle globalen Verwaltungsaufgaben der Blazor-App. Im Unterschied zu ­einer Blazor-Web-App übernimmt die App.razor-Datei auch das Routing einer Blazor-WebAssembly-App (SPA).

Weitere .NET-Ressourcen bereitstellen und ­die Fluent-Blazor-App starten

Ergänzend zu den beiden Ordnern Layout und Pages sowie den diskutierten Razor-Komponenten finden sich in einem Fluent-Blazor-Projekt noch drei weitere Dateien und ein Ordner: die Projektdatei, die Bootstrap-Datei (auch Startdatei des Programms genannt) Program.cs, ­eine launchSettings.json-, eventuell eine appsettings.json-Datei und der Ordner wwwroot. Die zentrale Projektdatei entspricht dem für die Web-App vergebenen Namen mit der im Solution-Explorer nicht angezeigten Datei-Erweiterung .csproj. Diese Projektdatei verweist auf die seitens der App benötigten Ressourcen. Neben einem Verweis auf das .NET SDK als Target-Framework beschreibt der Inhalt der Projektdatei, welche NuGet-Packages die App benötigt.Dabei greift eine Fluent-UI-Blazor-App im Fall einer reinen WebAssembly-App (SPA) für das Rendering lediglich auf das NuGet-Package Microsoft.AspNetCore.Components.Web­Assembly zurück. Kommt zusätzlich auch SSR zum Einsatz, so referenziert die Projektdatei auch das NuGet-Package Microsoft.AspNetCore.Components.WebAssembly.Server. Für die Ausführung der Web-App kommt für den Entwicklungsserver Microsoft.AspNetCore.Components.WebAssembly.Dev­Server zum Einsatz. Im Fall einer PWA enthält die Projektdatei einer Blazor-WebAssembly-App (SPA) eine Referenz auf deren service-worker.js-Datei.Da jede Fluent-UI-Blazor-App auf Fluent UI basierende Webkomponenten einsetzt, enthält die Projektdatei *.csproj auch zwei Referenzen auf die beiden Packages Microsoft.FluentUI.AspNetCore.Components sowie Microsoft.FluentUI.Asp­NetCore.Components.Icons. Ergänzend ermöglicht eine Referenz auf das Package Microsoft.FluentUI.AspNetCore.Components.Emoji den Einsatz der Emojis des Design-Systems Fluent im Projekt.Die Bootstrapping-Datei des Projekts, welche die Web-App als erste zum Startzeitpunkt ausführt, heißt Program.cs. Sie stellt dem Projekt die in der Projektdatei spezifizierten Ressourcen bereit, konfiguriert diese und startet den Builder für das Hosting der App. Anschließend fügt der Builder die benötigten RootComponents, die erforderlichen Services seitens des Blazor-Frameworks und die Fluent-UI-Webkomponenten hinzu. Dabei bringt Program.cs auch den zur Ausführung der Web-App benötigten HTTP(S)-Entwicklungsserver und eventuell weitere Middleware zum Laufen und startet abschließend die Web-App im Browser. Angaben zur Ausführung der Web-App (Port-Adressen und Ähnliches) enthält die launchSettings.json-Datei im Ordner Properties.Bei der Neuanlage eines Projekts legt nur das Template fluentblazor für eine Fluent-Blazor-Web-App eine appsettings.json-Datei direkt im Projektordner an. Im Fall eines Blazor-WebAssembly-Projekts sollte der Entwickler diese nachträglich einrichten, sobald die Web-App auch eine serverseitige Konfiguration benötigt. Bei dieser Vorgehensweise entfällt eine Konfiguration im C#-Code. Als Ablageort für die appsettings.json-Datei einer Fluent-Blazor-WebAssembly-App empfiehlt es sich, den Ordner wwwroot zu wählen. Dieser Ordner enthält Referenzen auf alle statischen Dateien und Ressourcen (Styles, Bilder, Skripte, externe Bibliotheken), die die Web-App zur Ausführung benötigt.In der appsettings.json-Datei befinden sich alle anwendungsseitigen Konfigurationsinformationen; diese liest die Web-App, um Zugriffe auf Datenbanken, Hosts oder Logging vorzunehmen, API-Endpunkte aufzurufen oder den HTTP(S)-Entwicklungsserver auszuführen. Sensible Daten sollten in ihr nicht direkt aufgenommen werden; vielmehr sollten diese über Umgebungsvariablen in der appsettings.json geschützt werden. Rechtliche Bestimmungen können eine Verschlüsselung zwingend erforderlich machen. Der Zugriff auf die Einträge der appsettings.json erfolgt über die IConfiguration-Schnittstelle von ASP.Net Core.

Customizing einer Fluent-UI-Blazor-App über das Starterprojekt durchführen

Für die Anpassung des Quellcodes der Fluent-UI-Blazor-App empfiehlt es sich, das Starterprojekt zunächst auf der Anwendungsebene zu erkunden. Die beiden für die Neuanlage des Starterprojekts verfügbaren Template-Typen/Vorlagen generieren – vom UI und der Funktionalität aus betrachtet – identische Apps. Auch unterscheidet sich die Funktionalität der von den Fluent-UI-Blazor-Templates generierten Web-Apps nicht von derjenigen der beiden reinen Blazor-Templates. Der Unterschied liegt im Quellcode: Das Fluent-UI-Blazor-Template bezieht automatisch die passenden Fluent-UI-Webkomponenten für die Benutzeroberfläche in das Starterprojekt ein.Die generierte Web-App besteht aus dem Tab im Web­browser und einem Seitentitel im Anzeigebereich der Webseite; darunter erscheint links eine Navigationsleiste mit drei Auswahlmenüs: Home, Counter und Weather(Bild 5). Aufbau und Strukturierung der Webseite übernimmt die Razor-Komponente MainLayout.razor. Der Quellcode der Navigationsleiste befindet sich in der Razor-Komponente NavMenu.razor. Nach Auswahl eines der drei Menüeinträge zeigt die Web-App die mit dieser Webseite verbundene Fluent-UI-Blazor-Komponente an. Gleichzeitig ändert sich die im Tab des Browsers angezeigte Titelzeile – es erscheint der Name der aktuell ausgewählten Webseite. Die drei Komponenten der Navigationsleiste sind als Razor-Komponenten Home.razor, Counter.razor und Weather.razor realisiert.

Den eigentlichen Startvorgang einer App führt ein Klick auf einen der beiden Einträge Run oder Starten ohne Debugging in der Toolleiste der IDE oder über das Terminalfenster der dotnet run- beziehungsweise dotnet watch-Befehl im Projektverzeichnis aus. Um vorgenommene Änderungen im Quellcode der Web-App sofort in der Ausführung über den Entwicklungsserver zu sehen, empfiehlt es sich, den dotnet watch-Befehl anstelle von dotnet run zu verwenden. Der SDK-Befehl watch startet ein Dateiüberwachungstool als Hintergrundprozess und aktiviert so das Hot-Reload-Feature. Das Überwachungstool überführt alle im Quellcode durchgeführten Änderungen an den Build-Prozess, und Hot Reload zeigt diese sofort in der laufenden Web-App an. Innerhalb der Visual-Studio-IDE aktiviert der Programmierer das Hot-Reload-Feature über dessen Icon-Symbol in der Toolleiste oder die Tastenkombination [Alt] + [F10].Für Änderungen im Quellcode zur Anpassung des generierten Starterprojekts erweist sich besonders die Funktion Suchen in Dateien als nützlich. So hilft diese Funktion beim schnellen Auffinden der benötigten Stellen im Quellcode, die beim Customizing zu ändern sind. Sie liefert eine Liste mit Dateien zurück, welche die gesuchte Zeichenkette enthalten. Durch Doppelklick auf den Dateinamen öffnet die IDE die zugehörige Datei im Quellcode-Editor, um direkt die gewünschten Änderungen anzupassen. Da Visual Studio die Such-Funktion auf den Quellcode in Dateien beschränkt, findet der Programmierer sofort die relevante Stelle. Sowohl VS Code als auch Visual Studio unterstützen reguläre Ausdrücke, die Vorgabe von Dateitypen und eine Spezifikation des Suchorts/Suchpfads.

Webkomponenten der Fluent-UI-Blazor-Library erkunden

Für ein weiteres Customizing des Starterprojekts, insbesondere um die Web-App mit neuen Webkomponenten zu erweitern, benötigt ein Entwickler Kenntnisse zu den in der Fluent-UI-Blazor-Library [8] enthaltenen Komponenten. Das Microsoft-Team der Fluent-UI-Blazor-Library unterteilt deren Webkomponenten in drei Gruppen:

• Layout: Alle Komponenten dieser Gruppe übernehmen das Layouting der Web-App. Dazu gehören unter anderem Header, Footer, ­BodyContent, Grid, Layout, MainLayout. Ausgangspunkt für das Layouting der Web-App stellt die FluentLayout-Komponente dar – dabei handelt es sich um einen Container, der andere Komponenten zur Gestaltung ins Layout aufnimmt. Eine weitere Container-Komponente stellt FluentStack dar – diese erlaubt eine horizontale oder vertikale Strukturierung der enthaltenen Elemente. Für die Definition von Abständen zwischen den Layout-Elementen dient die FluentSpacer-Komponente.
• Form & Inputs: Die Komponenten dieser Gruppe befassen sich mit der Definition und Verarbeitung von Formularen. Sie enthält Komponenten wie Eingabefelder, Textbereiche, Checkboxen, Radio-Buttons, Kalender, Slider, Ein/Aus-Schalter und Suchfelder. Die Komponenten eines Formulars können auch mit einer Funktionalität verknüpft sein, die der Endbenutzer durch Interaktionen mit der App auslöst.
• Components: In dieser Gruppe befinden sich die meisten Webkomponenten der Fluent-UI-Blazor-Library. Dazu gehören alle Komponenten, die man nicht den ersten beiden Gruppen zuordnen kann. Als besondere Mitglieder sind Overflow, Overlay, Persona, Popover, Toolbar, Tooltip, Tree View und Wizard hervorzuheben. Diese Komponenten bieten dem Endbenutzer eine herausragende Mächtigkeit, die mit Fluent UI Blazor viel leichter als mit anderen UI-Frameworks zu programmieren ist. So lässt sich mit der Wizard-Komponente ein mächtiger Assistent für den Endbenutzer in der App spezifizieren; dieser verfügt über verschiedene, noch näher zu spezifizierende Arbeitsschritte.

Über die Homepage den Quellcode für die Web-App inspizieren und erweitern

Auf der Homepage der Fluent-UI-Blazor-Library [9] befinden sich in der linken Navigationsleiste die zuvor erläuterten Gruppen der Webkomponenten. Dort erhält ein Programmierer ausführliche Erläuterungen zu einer bestimmten Webkomponente. Jede Fluent-UI-Blazor-Komponente vermittelt dem Programmierer einen Querbezug zum passenden ­HTML-Element und der W3C-Spezifikation. Ausgangsbasis für alle Komponenten der Fluent-UI-Blazor-Library bildet als Wurzelelement in der Vererbungshierarchie FluentComponentBase; diese Wurzelkomponente reicht ihre originären Parameter an alle anderen weiter. Zu jeder Webkomponente werden ferner ihre Basiskomponente, ihre zusätzlichen Parameter, EventCallbacks und Methoden beschrieben.Alle Beispiele der Webkomponenten, die eine visuelle Darstellung enthalten, besitzen rechts oberhalb zwei Registerkarten: Example und Razor. Ein Klick mit dem Mauszeiger auf Example zeigt die visuelle Darstellung der Webkomponente an. Möchte der Programmierer den zugehörigen Quellcode einsehen, so genügt ein Klick auf die Registerkarte Razor. Dann erscheint anstatt der visuellen Darstellung der zugehörige Quellcode für die Razor-Komponente. Den dortigen Razor-Code kann man über das Clipboard in die Web-App kopieren und im Quellcode-Editor der IDE entsprechend an die eigenen Anforderungen anpassen.Interessiert sich ein Entwickler für die Realisierung eines bestimmten Sachverhalts mit einer Fluent-UI-Blazor-Webkomponente, so bietet die Homepage der Fluent-UI-Blazor-Library auch hierzu eine Unterstützung an. Nach Auswahl der gewünschten Webkomponente über deren linken Eintrag bei der jeweiligen Gruppe erscheint ganz rechts in der Webseite ein Textbereich In this article. Dabei handelt es sich um eine Drop-down-Liste mit verschiedenen Texteinträgen (Bild 6). Unter diesen Texteinträgen findet der Programmierer in der Überschrift eine möglichst passende Textbeschreibung zu seiner aktuellen Problemstellung. Ein Klick mit der Maus auf diese Textbeschreibung, und die Webseite bietet nähere Hilfestellungen an [9].

Theming für Web-App einrichten und für Endbenutzer zur Auswahl anbieten

Über Theming stellen Endbenutzer das Erscheinungsbild einer Web-App auf persönliche Präferenzen ein. Grundsätzlich besitzt jede Fluent-UI-Blazor-App für das Theming zwei Standard-Themes: Light und Dark. Normalerweise ist in der Web-App das Light-Theme aktiviert. Eine FluentDesignTheme-Komponente führt das Theming für die komplette App durch. Individuelle eigene Vorgaben für Themes deklariert der Programmierer mithilfe von Design Tokens. Die Spezifikation dieser Design Tokens erfolgt über Fluent UI Web Components (siehe den vierten Teil dieser Serie unter [7]) auf Basis von FAST.Nach erfolgter Spezifikation von Themes speichert der Designer/Programmierer deren Einstellungen im lokalen Speicherbereich des Browsers ab. Jedes Theme im lokalen Speicherbereich besteht aus einer mode- und einer primaryColor-Property. Anhand des Parameters StorageName der FluentDesignTheme-Komponente erhält der Programmierer Zugriff auf ein gewünschtes Theme, um in der Web-App entsprechend zu reagieren. Damit das Default-Theme für alle Seiten der Web-App greift, muss es in der App.razor-Datei oder in einer Layout-Page referenziert werden: <FluentDesignTheme Storage­Name=”dateiname” />.Für die Festlegung der Themes durch den Endbenutzer bietet die Web-App ihm über eine Schaltfläche oder Drop-down-Liste passende Themes zur Auswahl an (Listing 3). Mit der Anweisung @using Microsoft.FluentUI.AspNetCore.Com­ponents.DesignTokens erhält der Programmierer Zugriff auf den Namespace der Design Tokens. Über den Dependency-Injection-Mechanismus (DI) von .NET stehen Services für die Helligkeit/Mode und die Farbe über die @inject-Anweisung zur Verfügung.

Helligkeit/Mode stellt der Endbenutzer über einen Fluent-UI-Schieberegler <FluentSwitch> auf Hell oder Dunkel ein (Listing 3). Dessen @bind-Value=”@IstDunkel” setzt die gewünschte Einstellung für Helligkeit/Mode. Einstellungen für die Farbe bietet die Web-App dem Endbenutzer über eine FluentUI-Drop-down-Liste <FluentSelect> zur Auswahl an. Anhand der @bind-SelectedOption=”@Farbe” bestimmt die Auswahlliste die gewünschte Farbeinstellung (Listing 3). Nach erfolgter Auswahl durch den Endbenutzer führt die Web-App die Theming-Vorgaben über die durch den obigen Namespace eingebundenen Services im @code-Bereich des DI-Mechanismus aus.

Leistungsstarke Services stehen in der Fluent-UI-Blazor-Library bereit

Services in einer Blazor-App stellen bestimmte Funktionalitäten bereit, die mehrere Blazor-Komponenten verwenden können. Typische Anwendungsfälle von Services sind der Zugriff auf externe Ressourcen, das Bereitstellen von Daten oder die Implementierung von Geschäftslogik.Das Microsoft-Team von Fluent UI Blazor macht über die Library einige Services direkt dem Entwickler zugänglich [10]:

• DialogService: Dieser Service ermöglicht es, in der Blazor-App Dialog- und Modal-Fenster zu erstellen. Die Implementierung des DialogService übernimmt ein DI-Mechanismus. Das Rendern findet typischerweise in der MainLayout.razor-Datei über die <FluentDialogProvider />-Komponente statt. Für das Weiterreichen von Benutzerdaten vom ­Dialog an die Web-App steht als Referenz das Feld DialogResult zur Verfügung. Alternativ kann der Programmierer auf einen EventCallback zurückgreifen, der sich bei den DialogParameters befindet.
• MessageService: Dient zum Anzeigen modaler Nachrichten, die von besonderer Bedeutung für den Endbenutzer sind. Nachrichten können barrierefrei gestaltet werden, sodass sie auch für Benutzer mit eingeschränktem Seh- und Hörvermögen zugänglich sind. Am Anfang injiziert man den MessageService in der Blazor-Komponente, programmiert im @code-Bereich die benötigten Methoden und initialisiert die Properties mit geeigneten Werten. Damit das Rendering korrekt erfolgt, muss in die MainLayout.razor-Datei der <FluentMessageBarProvider /> aufgenommen werden
• ToastService: Dieser Fluent-UI-Blazor-Service führt die Anzeige von Benachrichtigungen (sogenannten Toasts) in der Web-App durch. Bei diesen Toasts handelt es sich um kleine, nichtmodale Benachrichtigungen (Bild 7), die temporär auf dem Bildschirm erscheinen, um den Benutzer über bestimmte Ereignisse oder Aktionen zu informieren. Dazu gehören wichtige Informationen wie Erfolgs- oder Fehlermeldungen oder auch Warnhinweise. Die Implementierung dieses Service erfolgt über einen DI-Container. Das Rendern der Benachrichtigungen übernimmt die Komponente <FluentToastProvider />, diese muss sich in der MainLayout-Komponente (MainLayout.razor) befinden.

Mit Komponenten und UX-Design kompatibel zur Microsoft-Welt

Analog den Komponenten in der Softwareentwicklung wirkt sich auch ein User-Experience-Design (UX-Design) positiv auf Produktivität und Effizienz aus. UX-Design beeinflusst den Erfolg des gesamten Unternehmens, da die mit ihm verbundenen Features zu einer steigenden Akzeptanz bei den Anwendern und somit zu einer höheren Digitalisierung beitragen. Die im Unternehmen notwendige digitale Transformation zur Integration digitaler Technologien schreitet mit Komponenten und UX-Design schneller und vor allem mit ­einem höheren Mehrwert für das Unternehmen voran.Daher sollte die Softwareentwicklung ein Design-System wie FAST/Fluent von Microsoft verwenden, das mit intuitiver Bedienbarkeit zur besseren Verständlichkeit in allen Apps beiträgt. Gleichzeitig besitzt FAST/Fluent eine inhärente Kompatibilität zur Microsoft-Welt: Die Komponenten von Fluent UI Blazor bieten (abgestimmt auf FAST/Fluent) das Look-and-feel mo­derner Microsoft-Anwendungen. Aus den zuvor genannten Gründen sollte daher eine Entwicklungsorganisation für die eigenen Apps durchgängig das Komponentenpaket Fluent UI Blazor einsetzen, zumal die in Fluent UI Blazor enthaltene Softwaretechnologie Blazor auch eine hohe Sicherheit für die getätigten Investitionen gewährleistet.

Fussnoten

1. [1] Homepage von Blazor, https://blazor.net/
2. [2] Frank Simon, Design-Systeme für UI-Komponenten, dotnetpro 4/2024, Seite 21 ff., http://www.dotnetpro.de/A2404FluentUI
3. [3] Homepage von FAST, http://www.fast.design
4. [4] Microsoft-Download-Seite, dotnet.microsoft.com/en-us/download,
5. [5] Homepage von NuGet, http://www.nuget.org
6. [6] Homepage von Fluent 2, https://fluent2.microsoft.design/
7. [7] Frank Simon, Web-Apps mit Fluent UI Web, dotnetpro 8/2024, Seite 48 ff., http://www.dotnetpro.de/A2408FluentUI
8. [8] GitHub-Repository der Fluent-UI-Blazor-Library, https://github.com/microsoft/fluentui-blazor
9. [9] Demo-Site, Dokumentation der Fluent UI Blazor ­Components, http://www.blazorfluentui.net
10. Homepage der Fluent-UI-Blazor-Library, http://www.fluentui-blazor.net