© best_vector/Shutterstock.com
Ein SPFx Web Part für die Anzeige von Code

Einführung in SharePoint Framework


Der folgende Artikel zeigt, wie sich ein einfaches Client-side Web Part oder SPFx Web Part mit SharePoint Framework [1] erstellen lässt. Da es im aktuellen SharePoint Online nicht möglich ist, Codebeispiele in eine „Modern Page“ einzufügen, wird als Beispiel die Erstellung eines einfachen Web Parts für die Darstellung von formatiertem Code gewählt.

Wer sein erstes SPFx Web Part schreibt, sollte vorher einen Blick in den Artikel zur Einrichtung der Umgebung werfen [2]. Die benötigten Elemente sind die folgenden: ein aktuelles npm [3], Yeoman [4], gulp [5] und der SharePoint-Generator für Yeoman [6]. Wenn schon eine Version von npm installiert ist, reicht folgendes Statement aus, um die notwendigen Elemente auf dem System global zu installieren.

> npm install -g npm yo gulp @microsoft/generator-sharepoint

Scaffolding

Die Erstellung eines Web Parts beginnt mit der Generierung eines Gerüsts (Scaffolding). Grundlage dafür sind Yeoman und der SharePoint-Generator für Yeoman. Dieser Code zeigt die notwendigen Schritte zum Erstellen eines Verzeichnisses und zum Starten der Generierung:

> mkdir spfx-code-show
> cd spfx-code-show
> yo @microsoft/sharepoint

Der SharePoint-Generator wird zum Start fünf Punkte abfragen: Name der Lösung, Ablage der Dateien, verwendetes JavaScript-Framework, Name des Web Parts und eine Beschreibung. Die verwendeten Antworten zeigt Abbildung 1.

image

Abb. 1: Start der Generierung mittels Yeoman und SharePoint-Generator

Da bei der lokalen Entwicklung mit SharePoint Framework keine „echten“ SSL-Zertifikate zum Einsatz kommen, sollte man den Entwicklerzertifikaten etwas Vertrauen entgegenbringen. Der gulp-Task trust-dev-cert versucht ein Zertifikat entsprechend vertrauenswürdig zu hinterlegen, die nachfolgende Sicherheitsabfrage sollte dann mit „Ja“ beantwortet werden. Der generierte Code ist in sich schon lauffähig und kann mittels des gulp-task serve auch schon direkt gestartet werden. Der nachfolgende Code zeigt den Start und Abbildung 2 das Ergebnis.

> gulp trust-dev-cert
> gulp serve
image

Abb. 2: Das soeben neu erstellte Web Part „AddSomeCode“ wird in der SharePoint Workbench angezeigt

Verzeichnisstruktur und Aufbau der Lösung

Der Verzeichnisaufbau innerhalb der Lösung ist für „normale“ SharePoint-Entwickler etwas ungewohnt. Listing 1 zeigt den Ausschnitt einer settings.json, die für VSCode [7] die (vorerst) nicht benötigten Verzeichnisse ausblendet.

"files.exclude": {
"**/.*": true,
".vscode/": true,
"temp/": true,
"lib/": true,
"dist/": true,
"deploy/": true,
"node_modules/": true
}

Listing 1: „exclude“ in der „settings.json“

Die in der Lösung vorhandenen Verzeichnisse haben die folgende Bedeutung: Im Verzeichnis config finden sich alle Konfigurationen der Lösung, z. B. der Ausgabepfad der Bundle-Datei oder welche externen Bibliotheken eingebunden werden sollen. Im Verzeichnis typings finden sich alle externen TypeScript-Typings und im Verzeichnis src schließlich die Quellen des neu erstellten Web Parts. Die (aktuell ausgeblendeten) Verzeichnisse temp, lib, dist und deploy enthalten u. a. die generierten Dateien für die spätere Auslieferung (Abb. 3). Das Verzeichnis node_modules entsteht durch die Verwendung von npm und beinhaltet alle node-Module.

image

Abb. 3: Die Verzeichnisstruktur des neu erstellten Web Parts

Im Verzeichnis src/webparts/addSomeCode befinden sich die Quellen, die für das erstellte Web Part zuständig sind: Die Datei addSomeCode.module.scss ist eine sass-Datei [8], in der alle Formatierungen liegen. Die Datei addSomeCode.module.scss.ts ist direkt aus der .scss-Datei erstellt und beinhaltet die verwendeten Klassen als Konstanten, um diese wiederum bei der Erstellung der DOM-Elemente zu verwenden. Dies wird so gehandhabt, damit Entwickler sich nicht um Kollisionen in ihren css-Klassen sorgen müssen. Wenn zum Beispiel eine css-Klasse ok-button erstellt wird, muss sich der Entwickler fragen, ob es nicht schon eine derartige css-Klasse auf der Seite gibt und ob sein Code zu unerwünschten Seiteneffekten mit anderem Code auf der Seite führt. Um das zu verhindern, werden alle Klassendefinitionen, die in einem SPFx-Framework-Web-Part erstellt werden, um einen zufälligen Schlüssel ergänzt. Abbildung 4 zeigt die Umsetzung von (s)css-Klassen in TypeScript-Konstanten und auch den Schlüssel hinter dem Klassennamen (die grüne Markierung zeigt die Umsetzung des Klassennamens in TypeScript, die rote die Erweiterung um den Schlüssel). Dies macht die css-Klassen eindeutiger, führt aber auch dazu, dass man im zu erstellenden DOM nicht einfach <div class="ok-button"> schreiben kann. Stattdessen sollten immer direkt die TypeScript-Konstanten verwendet werden.

image

Abb. 4: Links ein Ausschnitt aus scss und rechts aus TypeScript

Die Dateien AddSomeCodeWebPart.ts und IAddSomeCodeWebPartProps.ts definieren die Eigenschaften bzw. das Verhalten des Web Parts. Die Datei IAddSomeCodeWebPartProps.ts ist, wie am Namen ersichtlich, ein Interface und definiert alle Eigenschaften des Web Parts. Aktuell ist die Datei sehr übersichtlich gestaltet und definiert g...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang