Wie funktionierts

Übergreifende Anleitungen zum Zusammenspiel der Komponenten.

Bundles

  • Bundles im Überblick JavaScript und Styles der Komponenten werden zur Laufzeit zu wenigen Dateien zusammengefasst. Dahinter steht LigerShark.WebOptimizer und ein schmaler Aufsatz in FMH.Komponente.Infrastruktur, der die Beiträge der Pakete einsammelt.
  • JavaScript einbinden Eine neue Komponente bringt ihr JavaScript über eine Klasse ins Bundle. Der Regelfall ist das Standard-Bundle fmh-scripts, das über BodyIncludes am Seitenende geladen wird.
  • SCSS einbinden Styles laufen über dieselbe Mechanik wie JavaScript, nur über die Schnittstelle IScssStyleProvider. Kompiliert wird zur Laufzeit von LigerShark.WebOptimizer.Sass.
  • Eigene Bundle-Namen und Grenzfälle Ein abweichender BundleName erzeugt einen eigenen Endpunkt. Das ist schnell gemacht, und genauso schnell übersehen, dass ihn niemand ausliefert.
  • Native ES-Module einbinden Module gehören nicht ins Bundle, NUglify versteht import/export nicht. Sie laufen deshalb über einen zweiten, bewusst schmalen Weg: den Modulkatalog. Er funktioniert wie das Bundle, nur dass er keine Datei zusammensetzt, sondern Adressen verwaltet.

Logging

  • Logging im Überblick Meldungen aus dem Browser landen im selben Serilog-Strom wie die Meldungen des Servers, dafür greifen drei Bausteine ineinander.
  • Server einrichten So ist Serilog in dieser Anwendung (FMH.Komponente.WebUI) konfiguriert, die Ausschnitte stammen unverändert aus Program.cs, appsettings.json und der Projektdatei.
  • Logging im Browser Das Modul fmh-web-log aus dem Paket Serilog.Sinks.JavaScript protokolliert aus dem Browser heraus an den Endpunkt /siwflog. Es ist über das Layout bereits eingebunden, es gibt nichts zu registrieren.
  • Blazor WASM anbinden In einer Blazor-WebAssembly-Oberfläche gibt es kein FMH-Layout und damit kein fmh-web-log. An seine Stelle tritt FMH.Komponente.Serilog.Sinks.Blazor.WASM, ein Serilog-Sink, der im Browser läuft und an denselben Endpunkt sendet.

Pakete

  • Pakete im Überblick Die Komponenten werden einzeln ausgeliefert, je Komponente ein NuGet-Paket mit eigener Version. Eine Anwendung nimmt also genau die Pakete, die sie braucht, und hebt sie einzeln an.
  • Sub-Komponenten einzeln referenzieren Fünf Pakete sind aus einer bestehenden Komponente herausgetrennt: FMH.Komponente.Basis.Validierung, FMH.Komponente.FileUpload.Validierung, FMH.Komponente.Kompetenzen.Validierung, FMH.Komponente.RichText.Validierung und FMH.Komponente.Infrastruktur.Schnittstellen. Diese Seite sagt, was sie enthalten, wann der einzelne Bezug sich lohnt und was dabei fehlt.
  • Template-Namen und Metadaten-Schlüssel Ein ViewModel-Feld mit FMH-Template braucht oft zwei Angaben: welches Template es rendert und wie dieses Template konfiguriert ist. Dafür gibt es zwei Einstiege. UiEditor und UiDisplay gehören zu [UIHint], UiMetadata gehört zu [AdditionalMetadata]. Diese Seite erklärt, warum das so getrennt ist.