Seit der SharePoint Framework Version 1.9 gibt es ein lang erwartetes Feature: SPFx Libraries. Dieser Blogbeitrag wird keine Schritt für Schritt Anleitung, wie man die Libraries verwendet. Stattdessen werden wir uns anschauen, welche Vorteile es bringt die Library Komponenten zu verwenden.
Das Problem
Stellen Sie sich vor Sie haben eine Webseite auf der Sie 4 SPFx Webparts einsetzen. All diese Webparts verwenden die gleichen Dienstklassen, um mit der SharePoint REST-API zu kommunizieren sowie ein paar wiederwendbare React Komponenten.
Wenn Sie den Standard-Prozess zum Bundlen von Solutions verwenden (gulp bundle –ship && gulp package-solution –ship), enthalten all Ihre Lösungen zu einem mehr oder weniger großen Anteil den gleichen Code. In unserem Beispiel müsste die Seite den gleichen Code vier Mal laden. Das ist nicht sehr effizient und kann sich negativ auf die Ladezeit auswirken. Außerdem ist es eine übliche Vorgehensweise, wiederverwendbare Codeteile in eine separate Bibliothek zu verschieben
Die Lösung ohne Library Komponente
Der gemeinsame Code wird aus der SPFx Solution gehoben und in eine eigene Bibliothek gepackt.
Problem 1: Sämtliche Schritte zum Erstellen einer Solution (zB.: Typescript Compiler, webpack bundling, tslint) müssen manuell angepasst werden
Problem 2: Wir wollen eine Referenz auf unseren Code in allen Webparts verwenden. Hierfür müssen wir unser Package an einer Stelle hosten, die für alle zugänglich ist. Das Office 365 CDN bietet sich hierfür an, da es schon im Tenant inkludiert ist. Nach der Konfiguration müssen wir uns darum kümmern, dass das Package an der richtigen Stelle hochgeladen wird und die Referenz in unserem SPFx Projekt mit einem „externals“ Eintrag in der config.json hinzufügen.
Warum wird das Paket als extern hinzugefügt? Um zu verhindern, dass es in das Webpart Paket inkludiert wird.
Wenn wir versuchen die gemeinsame Komponente in unserem Projekt zu verwenden, bekommen wir eine Fehlermeldung, da unser SharePoint Framework das Modul nicht kennt. Mit dem Befehl npm link „Komponentenname“ können wir eine Abhängigkeit in unserem Projekt erstellen. Diese wird im Ordner node_modules abgelegt.
Problem 3: Trotz npm link ist es nicht möglich die lokale Workbench zu verwenden, da die im Office 365 CDN gehosteten Dateien lokal nicht geladen werden. Es bleibt uns also nur die Möglichkeit die gehostete Workbench zu verwenden.
Problem 4: Änderungen am geteilten Code werden erst sichtbar, wenn wir das veränderte Package in Office 365 CDN hochgeladen haben.
Was gilt es zu beachten?
Die SPFx build pipeline fügt den gemeinsamen Code nicht in unsere Webpart Komponente ein, da wir sie als „extern“ hinzugefügt haben.
Sobald eine Seite einen Webpart mit „externer“ Komponente beinhaltet, lädt die SPFx Engine den externen Code bevor der Webpart ausgeführt wird. Wichtig: Das gemeinsame Modul wird nur ein Mal geladen, egal wie oft es aufgerufen wird.
Als Ergebnis der Prozedur haben wir es geschafft das eingangs erwähnte Problem zu lösen. Gemeinsamer Code wird nur noch einmal geladen. Der Preis für den Performance Gewinn ist ein erhöhter Aufwand bei der Entwicklung und beim Deployment.
Die Lösung mit Library Componente
Im folgenden werde ich beschreiben, wie man SPFx Library Komponenten verwendet und wie Sie die oben beschriebenen Probleme lösen.
Erstellen einer neuen Library Komponente
Library Komponenten werden wie SPFx Webparts und SPFx Extensions mit dem Befehl yo @microsoft/sharepoint erstellt.
Es ist wichtig bei dem Punkt „Do you want to allow the tenant admin the choice of being able to deploy the solution to all sites immediately without running any feature deployment or adding apps in sites?“ ja ausgewählt wird
Nach dem Erstellen haben wir nun ein Library Projekt bei dem Typescript, Webpack usw. bereits vollständig konfiguriert sind. Problem 1 ist damit gelöst und wir können sofort loslegen.
Um die Library Komponente in einem anderen Projekt zu verwenden wird auch hier mit npm link eine Verknüpfung zu der Komponente hergestellt. Diesmal können wir jedoch auch die lokale Workbench verwenden, da die SharePoint Framework Runtime Engine das Modul während der Laufzeit aus den node_modules lädt.
Änderungen, die wir am gemeinsamen Code vornehmen, sind mit gulp serve sofort sichtbar.
Somit haben wir Problem 3 und 4 auf einen Schlag gelöst.
Deployment der Library Komponente
Dieser Prozess ist extrem einfach. Wir erstellen mit „gulp bundle –ship && gulp package-solution –ship“ ein Package. Dieses laden wir in den Appcatalog und klicken auf die Checkbox, um die Library Global verfügbar zu machen. Damit haben wir auch Problem Nummer 2 gelöst.
Bedeutet das nun, dass die Library Komponente in jeden Webpart eingebunden wird, der darauf verlinkt? Nein. Im Grunde funktioniert eine SPFx Library genau so wie der oben beschriebene Prozess zum Erstellen einer Library ohne SPFx. Der Vorteil ist, dass sich das SharePoint Framework um alle Prozesse im Hintergrund kümmert und die tatsächlichen Verlinkungen erst zur Laufzeit passieren.
Fazit
Library Komponenten vereinfachen das Hosten von gemeinsam genutzten Webpart Code erheblich. Wenn Sie Seiten mit vielen Webparts haben, kann das Verschieben von gemeinsam genutztem Code in separate Libraries die Performance und Reaktionszeit der Seite stark verbessern.
