Entwicklung von Webparts mit SharePoint Framework

Entwicklung von Webparts mit SharePoint Framework

Teil 1 – Solution Struktur

Mithilfe des SharePoint Frameworks (SPFX) und anderen JavaScript -Tools und -Bibliotheken können clientseitige Webparts erstellt werden. Sie werden im Kontext einer SharePoint-Website ausgeführt und können in einer SharePoint-Onlineumgebung sowie lokalen SharePoint-Umgebung verwendet werden.

Für diesen Blog-Beitrag und die Serie werden Grund-Kenntnisse in der SPFX-Entwicklung mit React vorausgesetzt. Zur Einarbeitung werden die Blog-Beiträge von Microsoft empfohlen: https://docs.microsoft.com/de-de/sharepoint/dev/spfx/web-parts/get-started/build-a-hello-world-web-part

Da ein Webpart aus verschiedenen Komponenten besteht, ist es wichtig eine klare Struktur der Dateien bei der Entwicklung zu wählen, vor allem wenn mehrere Webparts entwickelt werden müssen. Wenn der Yeoman-SharePoint-Generator verwendet wird, um den Webpart initial zu erstellen, wird bereits eine grobe Struktur vorgegeben. Dieser Blog Beitrag stellt eine Vorgehensweise der Entwicklung vor, die mehrere Webparts einheitlich strukturiert und somit Wartbarkeit und Arbeiten in einem Team erleichtern soll.

Mehrere Webparts strukturieren

Da Webparts eigenständige und unabhängige clientseitige Komponenten sind, kann eine Solution pro Webpart erstellt werden oder eine Solution für alle Webparts. Für ein Projekt wurde entschieden alle Webparts in eine Solution zu organisieren, da die Webparts nicht in anderen Projekten wiederverwendet werden sollen und so folgende Vorteile entstehen:

  • Helper-Klassen können mehrfach verwendet werden
  • NPM-Packages können mehrfach verwendet werden
  • “gulp serve” stellt alle Webparts zur Verfügung

Eine eigene Solution für einen Webpart macht vor allem dann Sinn, wenn der Webpart in mehreren Projekten eingesetzt oder als Produkt verkauft werden soll.

Datei-Struktur am Beispiel des novaworxx-Favoriten-Webparts

Für das Produkt novaWorxx der novaCapta wurde ein Webpart entwickelt, der Projekt-/Teamräume zeigt, denen der Benutzer folgt. Diese werden nach Bereich gruppiert. Die bewährte Vorgehensweise bei der Struktur wird am Beispiel des Favoriten-Webparts gezeigt.

Der Webpart zeigt favorisierte Räume nach ihrem Bereich strukturiert

Die Struktur auf der obersten Ebene sieht wie folgt aus:

Ordner-Struktur des Webparts

Der Webpart wurde mit dem React-Framework entwickelt. Es wird zwischen React-Komponenten, welche JSX verwenden (TSX-Dateien), Businesslogik (TS-Dateien) und weiteren notwendige Dateien, wie Text- oder JavaScript-Dateien, unterschieden.

Dateien, die den Webpart definieren und initialisieren, liegen in keinem Unterordner. React-Komponenten werden im Ordner “components” abgelegt. Die Business-Logik für die Abfrage und Aufbereitung von Daten befindet sich im Ordner “dataProviders”. Im Ordner “loc” sind Texte für die Mehrsprachigkeit und im Ordner “tests” liegen Unit Tests.

Webpart Dateien

Direkt im Webpart-Ordner auf der ersten Ebene befinden sich die drei Dateien, die den Webpart als SPFX-Webpart definieren. Das Manifest enthält neben anderen Informationen Titel, Beschreibung, ID und Standardwerte für Webpart-Eigenschaften.

Die Datei “FavoriteWebpart.ts” wurde initial von Yeoman erstellt. Sie initialisiert die erste React-Komponente und übergibt Werte der Webpart-Eigenschaften. Das Interface “IFavoriteWebPartProps.ts” beschreibt die Typen der Eigenschaften, welche an die erste Komponente übergeben und verarbeitet werden.

React Komponenten

In der Webpart-Datei “FavoriteWebpart.ts” wird die erste React-Komponente erstellt, welche als Einstiegspunkt für die Darstellung betrachtet werden kann. Die Klasse heißt normalerweise wie der Webpart, im Beispiel also “Favorite.tsx”. Pro Komponente wird ein eigener Ordner angelegt, in dem die Klasse und seine SCSS-Style-Datei zu finden ist. Die Klasseninterfaces wurden in einen Ordner “interfaces” unter “components” abgelegt.

Struktur der React-Komponenten

Die React-Komponenten enthalten JSX-Elemente und haben deshalb die Dateiendung “tsx”. Sie sind für das Rendering zuständig. Die JSX-Syntax verbindet HTML-Tags mit der vollen Funktionalität von JavaScript-Logik und wird bei der React-Entwicklung empfohlen.

Im Beispiel des Favoriten-Webpart wurden neben der Hauptkomponente “Favorite” noch “GroupSelector” und “ListContainer” erstellt.

  • Die “GroupSelector”-Klasse rendert die linke Seite des Webparts, also die Gruppen (Stockwerke).
  • Die “ListContainer”-Klasse rendert die rechte Seite des Webparts, also die einzelnen Elemente (Räume)

Die Kommunikation, das Event-Handling, übernimmt die Elternklasse “Favorite.tsx”, welche beide Komponenten erstellt.

Für jede React-Komponente sollte eine eigene klar definierte Aufgabe in der Darstellung des Webparts erkennbar sein. Des Weiteren macht es oft Sinn eine eigene Komponente zu erstellen, wenn die gleichen komplexeren Elemente mehrmals angezeigt werden sollen. So wird Verhalten und Design der Elemente zentral implementiert.

Daten- Abfrage und Aufbereitung

Im Ordner “dataProviders” liegen Klassen, welche Daten abfragen und aufbereiten. Die Abfrage wird von der ersten Haupt-React-Komponente asynchron gestartet. Während auf ein Ergebnis gewartet wird, kann ein Ladebildschirm angezeigt werden. Das Rendern der Daten und Warten auf die Abfrage übernimmt die React-Komponente.

Die Klassen in “dataProviders” sind dafür zuständig, die Daten von der richtigen Quelle abzufragen und in der erwarteten Struktur an die React-Komponente zu übergeben. Sie fangen Fehler ab und geben diese auch an die Render-Klasse zurück, sodass dem Benutzer eine sprechende Fehlermeldung angezeigt werden kann.

Die erwartete Datenstruktur wird von der React-Komponente über Interfaces vorgegeben, sodass jederzeit die Datenquelle ausgetauscht werden kann. Das bedeutet, dass für jede Datenquelle ein eigener Provider sich darum kümmern muss, die Daten in die erwartete Struktur zu überführen. Die Klasse, die entscheidet, welcher Daten-Provider verwendet wird, wird “MainDataProvider” genannt. Er entscheidet zum Beispiel je nach SharePoint-Umgebung oder Benutzereingabe in den Webpart-Eigenschaften. Er übernimmt das Starten des Providers und übergibt gegebenenfalls Fehler an die React-Komponente. Wenn eine neue Datenquelle implementiert werden muss, wird der Provider dazu geschrieben und der MainDataProvider erweitert, sodass er den neuen Provider kennt und startet. Die Render- und Business-Logik der React-Komponenten muss dabei nicht angepasst werden. Dieses Vorgehen in der Struktur erleichtert Erweiterungen und Komplexität des Webpart.

Die Dateistruktur im Beispiel des Favoriten-Webpart sieht wie folgt aus:

Datei-Struktur der Daten-Provider

Daten Abfrage am Beispiel

Räume sind Einträge in einer SharePoint-Liste, welche Informationen über ihren Bereich, also ihre Gruppe haben. Der “MainDataProvider” wird von der ersten React-Komponente “Favorite.tsx” asynchron gestartet. Die Komponente erwartet die Daten in einer bestimmten Struktur, welche im Interface “IFavoriteItems” beschrieben ist.

Start der Datenabfrage in der Hauptkomponente “Favorite.tsx”

Der “MainDataProvider” überprüft den Kontext des Webparts und startet den SharePointData-Provider, wenn sich der Webpart in SharePoint befindet, ansonsten wird der MockDataProvider gestartet. In der Entwicklungsseite, der sogenannten “Workbench”, auf der lokal entwickelt wird, ist der Kontext zum Beispiel nicht SharePoint. Damit trotzdem entwickelt werden kann, wurde ein “MockDataProvider” geschrieben.

Die beiden Variablen “this.props.sourceWebUrl” und “this.props.list” sind Webpart-Eigenschaften, die der Benutzer eingetragen hat.

Wenn der Webpart auf einer SharePoint-Seite hinzugefügt wird, wird der SharePointData-Provider gestartet. Er frägt die Liste ab, filtert nach favorisierten Räumen und erstellt das Ergebnis-Objekt in der Struktur des Interfaces “IFavoriteItems”. Fehler werden abgefangen, protokoliert und zurückgegeben.

Sobald die Datenabfrage erfolgreich abgeschlossen ist, wird die Hauptkomponente neu geladen und die Daten angezeigt. Das erneute Laden bei Änderungen der Daten im sogenannten State übernimmt das React-Framework. So werden Informationen einer entfernten Quelle, unabhängig von ihrem Kontext, abgefragt und dargestellt.

Helper

Wenn Methoden oder Interfaces in mehreren Webparts verwendet werden, können Helper-Klassen erstellt werden. Sie werden in einem Ordner in der gleichen Ebene wie die Webparts platziert.

Es ist sinnvoll, die Logging-Komponenten, Polyfills oder Erweiterungen der Eigenschaften-Leiste auszulagern. Darüber hinaus wurden im Rahmen des Projektes Interfaces von SharePoint-Objekten, die nicht vorliegen oder erweitert wurden, dort hinterlegt.

Fazit

Die vorgestellte Struktur hat sich im Produkt novaWorxx bewährt. Sie ist leicht erweiterbar und trennt die Komponenten des Webparts nach ihren Aufgaben. Wenn bei der Entwicklung von mehreren Webparts eine einheitlich und nachvollziehbare Struktur der Komponenten gewählt wird, senkt das die Komplexität, die Entwickler kennen sich schnell in der Solution aus und können Anpassungen zielgerichteter durchführen. Durch die Trennung von Darstellung und Datenabfrage ist die Erweiterung und Anpassung von Datenquellen vereinfacht.

By | 2018-04-16T15:13:38+00:00 April 16th, 2018|Allgemein, SharePoint, Web application|0 Comments

About the Author:

Associate Technology Specialist

Leave a Reply

%d bloggers like this:

novaCapta verwendet Cookies, um die Funktionalität dieser Website zu verbessern. Durch die Nutzung dieser Seite stimmen Sie der Verwendung von Cookies zu. Weiterlesen

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close