Migration von JSLink-Anpassungen zu Field Customizer für SharePoint-Framework

  • Artikel

Das SharePoint-Framework (SPFx) ist das empfohlene Modell zum Erweitern und Erstellen von SharePoint-Anpassungen. Wenn Sie SharePoint-Felder und -Listenansichten mit JSLink angepasst haben, fragen Sie sich vielleicht, welchen Vorteil die Migration dieser Anpassungen zu SPFx hat.

Bei der Entwicklung von SharePoint-Framework-Erweiterungen sind folgende Optionen verfügbar:

  • Application Customizer: Erweitert die native „moderne“ Benutzeroberfläche von SharePoint, indem benutzerdefinierte HTML-Elemente und clientseitiger Code den vordefinierten Platzhaltern der „modernen“ Seiten hinzugefügt werden. Weitere Informationen zu Anwendungsanpassungen finden Sie unter Erstellen Ihrer ersten SharePoint-Framework-Erweiterung (Hello World, Teil 1).
  • Command Set: Fügt benutzerdefinierte ECB-Menüelemente (Edit Control Block) oder benutzerdefinierte Schaltflächen zur Befehlsleiste einer Listenansicht für eine Liste oder Bibliothek hinzu. Sie können diesen Befehlen eine beliebige clientseitige Aktion zuordnen. Weitere Informationen zu Befehlssätzen finden Sie unter Erstellen Ihrer ersten Erweiterung des Typs „ListView Command Set“.
  • Field Customizer: Passt das Rendering eines Felds in einer Listenansicht mit benutzerdefinierten HTML-Elementen und clientseitigem Code an. Weitere Informationen zu Feldanpassungen finden Sie unter Erstellen Ihrer ersten Field Customizer-Erweiterung.

Je nach Ziel der Anpassung können Sie eine der oben genannten Konfigurationen nutzen. Field Customizer sind beispielsweise ein guter Ersatz für die JSLink-Anpassungen von Feldern.

Tipp

Während Field Customizer der natürliche Migrationspfad von JSLink sind, sollten Sie auch die Listen- und Spaltenformatierung verwenden, um die Listenansicht anzupassen. Beide Technologien haben ihre individuellen Vor- und Nachteile, und je nach Szenario kann eine einfacher zu implementieren und zu verwalten sein als die andere.

Weitere Informationen finden Sie hier: Verwenden der Spaltenformatierung zum Anpassen von SharePoint

Die SharePoint-Framework wurde entwickelt, um die moderne SharePoint-Oberfläche zu erweitern. Die "moderne" Benutzeroberfläche ist auf den modernen Teamwebsites und modernen Kommunikationswebsites verfügbar, die auf jedes Gerät und jede Plattform ausgerichtet sind.

Die einzige unterstützte Möglichkeit zum Anpassen von modernen Listen und Bibliotheken

Einer der Hauptvorteile der Migration älterer JSLink-Anpassungen zum SharePoint-Framework besteht darin, dass es die einzige unterstützte Option ist, die verfügbar ist. Tatsächlich können sich die "modernen" Listen und Bibliotheken aufgrund ihrer Renderinginfrastruktur und aufgrund des auf den "modernen" Websites aktivierten No-Script-Flags nicht auf ältere JSLink-Anpassungen verlassen. Wenn Sie die moderne Benutzeroberfläche wirklich erweitern möchten, müssen Sie die JSLink-Lösung zu einem SharePoint-Framework Field Customizer migrieren.

Einfacherer Zugriff auf Informationen in SharePoint und Microsoft 365

Ein weiteres grundlegendes Thema, das Sie berücksichtigen sollten, ist, dass es in den älteren JSLink-Anpassungen nicht einfach war, SharePoint-Inhalte und -Daten zu nutzen. Die einzige Möglichkeit dafür war die Verwendung des clientseitigen JavaScript-Objektmodells (JSOM) oder von REST-APIs auf niedriger Ebene. Es war fast unmöglich, den vollständigen Satz von Diensten von Microsoft 365 zu nutzen, es sei denn, Sie haben ADAL.JS (Azure Active Directory-Authentifizierungsbibliothek für JavaScript) und benutzerdefinierten JavaScript-Code verwendet.

Mit der SharePoint-Framework und den SharePoint-Framework-Erweiterungen ist es jetzt einfach und einfach, sowohl die SharePoint REST-API als auch Microsoft Graph zu nutzen. Sie können jetzt leistungsfähigere Lösungen erstellen, die das gesamte Ökosystem der von Microsoft 365 bereitgestellten Dienste nutzen und mit ihnen interagieren können.

Ähnlichkeiten zwischen SharePoint-Framework-Lösungen und SharePoint-Featureframework-Anpassungen

Sowohl die JSLink-Anpassungen als auch die SharePoint Feature Framework-Anpassungen weisen einige Ähnlichkeiten auf.

Bereitstellungsmodell

Sowohl SharePoint-Framework Erweiterungen als auch benutzerdefinierte Aktionen oder die ECB-Menüelementlösungen verwenden eine XML-Manifestdatei, die mit der SharePoint Feature Framework-Syntax geschrieben wurde. Daher basiert die Bereitstellung auf der gleichen Methode. Mit den neuen Field Customizern können Sie das Rendern eines Felds anpassen, jedoch nicht das Rendern einer einzelnen Ansicht einer Liste oder Bibliothek. Das benutzerdefinierte Feld kann in beliebig vielen Listen und Bibliotheken verwendet werden.

Ausführung als Teil der Seite

Ähnlich wie benutzerdefinierte Benutzeraktionen und ECB von SharePoint Feature Framework sind SharePoint-Framework Erweiterungen Teil der Seite. Damit haben diese Lösungen Zugriff auf das DOM der Seite und können mit anderen Komponenten auf der Seite kommunizieren. Zusätzlich macht diese Tatsache es Entwicklern leichter, ihre Lösungen dynamisch zu gestalten, sodass sie sich an die verschiedenen Formfaktoren anpassen können, in denen eine SharePoint-Seite angezeigt werden kann. Unter anderem wird auch die mobile SharePoint-App unterstützt.

Da SharePoint-Framework Erweiterungen als Teil der Seite ausgeführt werden, können alle Ressourcen, auf die die Anpassung zugriffsfertig ist, auch auf andere Elemente auf der Seite zugreifen. Das ist ein wichtiger Aspekt bei der Erstellung von Lösungen, die den impliziten OAuth-Fluss mit Bearerzugriffstoken nutzen oder vertrauliche Informationen in Cookies oder im Browserspeicher speichern. Da SharePoint-Framework Erweiterungen als Teil der Seite ausgeführt werden, können auch andere Elemente auf dieser Seite auf alle diese Ressourcen zugreifen.

Bibliotheksunabhängige Erweiterungserstellung

Bei der Erstellung von Seitenanpassungen mithilfe von benutzerdefinierten Aktionen haben Sie möglicherweise Bibliotheken wie jQuery und Knockout verwendet, um Ihre Anpassung dynamisch zu machen und sie besser auf Benutzerinteraktionen reagieren zu lassen. Wenn Sie SharePoint-Framework Erweiterungen erstellen, können Sie ihre Lösung mit jeder clientseitigen Bibliothek auf die gleiche Weise erweitern wie in der Vergangenheit.

Ein weiterer Vorteil des SharePoint-Framework ist die Isolierung Ihres Skripts. Obwohl das Webpart als Teil der Seite ausgeführt wird, ist das Skript als Modul verpackt. So können beispielsweise mehrere verschiedene Erweiterungen auf ein und derselben Seite jeweils eine andere jQuery-Version verwenden, ohne dass es zu Konflikten kommt. Das ist ein leistungsfähiges Feature, das es Ihnen ermöglicht, sich auf die Schaffung von konkretem geschäftlichem Mehrwert zu konzentrieren; technische Migrationen und Funktionskompromisse sind nicht mehr nötig.

Ausführung als aktueller Benutzer

Bei JSLink-Anpassungen war zur Kommunikation mit SharePoint lediglich ein Aufruf der entsprechenden API notwendig. Die clientseitige Lösung wurde im Browser im Kontext des aktuellen Benutzers ausgeführt; da der Authentifizierungscookie automatisch zusammen mit der Anforderung gesendet wurde, konnte die Lösung eine direkte Verbindung zu SharePoint aufbauen. Zur Kommunikation mit SharePoint war also anders als bei der Verwendung von SharePoint-Add-Ins keine zusätzliche Authentifizierung erforderlich.

Der gleiche Mechanismus wird auch bei SharePoint-Framework-basierten Anpassungen angewendet. Auch sie werden im Kontext des aktuell authentifizierten Benutzers ausgeführt und erfordern keine zusätzlichen Authentifizierungsschritte zur Kommunikation mit SharePoint. Der Sicherheitskontext ist der des aktuell verbundenen Benutzers, was bedeutet, dass Sie aus Sicherheitsgründen vorsichtig sein müssen, wenn Sie eine SharePoint-Framework Erweiterung in einer beliebigen Zielwebsitesammlung installieren.

Beschränkung auf clientseitigen Code

Sowohl SharePoint-Framework-Erweiterungen als auch JSLink-Anpassungen werden im Browser ausgeführt und können nur clientseitigen JavaScript-Code enthalten. Dabei gelten für clientseitige Lösungen mehrere Einschränkungen: Sie unterstützen beispielsweise keine Rechteerweiterungen in SharePoint und können auch keine Verbindung zu externen APIs aufbauen, die CORS (Cross-Origin Resource Sharing) oder die Authentifizierung per implizitem OAuth-Fluss nicht unterstützen. In solchen Fällen könnte die clientseitige Lösung eine serverseitige Remote-API nutzen, um den erforderlichen Vorgang auszuführen und die Ergebnisse an den Client zurückzugeben.

Hostingmodell selbstkonsistent und basierend auf Microsoft 365

Sowohl SharePoint-Framework-Erweiterungen als auch JavaScript-Dateien für JSLink-Anpassungen können auf SharePoint Online und schließlich im Microsoft 365 CDN-Dienst gehostet werden, wodurch externe Dienste oder Hostingumgebungen vermieden werden.

Während das Hosten SharePoint-Framework Lösungen in einem CDN viele Vorteile bietet, ist dies nicht erforderlich, und Sie können den Code in einer SharePoint-Dokumentbibliothek hosten. SharePoint-Framework im App-Katalog bereitgestellten Pakete (*SPPKG-Dateien) geben die URL an, unter der SharePoint-Framework den Code der Lösung finden können. Wenn der Benutzer der Seite mit der Erweiterung das Skript von dem angegebenen Speicherort herunterladen kann, gibt es keine Einschränkungen hinsichtlich des Ziels dieser URL.

Microsoft 365 bietet die öffentliche CDN-Funktion, mit der Sie Dateien aus einer bestimmten SharePoint-Dokumentbibliothek in einem CDN veröffentlichen können. Das öffentliche CDN von Microsoft 365 bietet ein gutes Gleichgewicht zwischen den Vorteilen der Verwendung eines CDN und der Einfachheit des Hostings von Codedateien in einer SharePoint-Dokumentbibliothek. Wenn Ihre Organisation nichts dagegen hat, dass ihre Codedateien öffentlich verfügbar sind, ist die Verwendung des öffentlichen Microsoft 365-CDN eine Option, die sie in Betracht ziehen sollten.

Zwischen den beiden Entwicklungsmodellen gibt es jedoch auch einige wesentliche Unterschiede, die Sie beim Entwerfen der Architektur Ihrer Lösungen berücksichtigen sollten.

Ausführung auf No-Script-Websites und in modernen Listen und Bibliotheken

Da SharePoint-Framework Lösungen, einschließlich Erweiterungen, mit einer vorherigen Genehmigung über den App-Katalog bereitgestellt werden, unterliegen sie nicht den No-Script-Einschränkungen und funktionieren auf allen modernen Websites. Wie wir bereits gesehen haben, funktionieren die Field Customizer von SharePoint-Framework in "modernen" Listen und Bibliotheken, während das legacy JSLink nicht funktioniert.

Szenarien, in denen nur die Ansicht von Field Customizern unterstützt wird

Eine JSLink-Anpassung kann nicht nur zum Anpassen der Ansicht eines Felds in einer Liste oder Bibliothek verwendet werden, sondern auch der Anzeige sowie zum Bearbeiten von Ansichten eines Felds beim Anzeigen eines einzelnen Elements.

Zum Zeitpunkt dieses Schreibens kann ein Field Customizer von SharePoint-Framework das Rendering eines Felds nur im Rendermodus der Listenansicht anpassen, während Sie in den Anzeige- und Bearbeitungsansichten eines einzelnen Elements die Anpassung nicht nutzen können.

Verwendung von TypeScript für stabilere und einfacher zu pflegende Lösungen

Bei der Erstellung von JSLink-Anpassungen haben Entwickler oft reines JavaScript verwendet. Solche Lösungen enthielten häufig keinerlei automatisierte Tests, und die Codeumgestaltung war fehleranfällig.

Mit dem SharePoint-Framework können Entwickler bei der Lösungserstellung das TypeScript-Typensystem verwenden. Dank dieses Typensystems fallen Fehler bereits während der Entwicklung auf, nicht erst zur Laufzeit. Auch die Codeumgestaltung ist einfacher, weil Änderungen am Code durch TypeScript gesichert werden. Da jeder JavaScript-Code gültiger TypeScript-Code ist, ist die Einstiegshürde niedrig, und Sie können Ihren reinen JavaScript-Code schrittweise zu TypeScript migrieren. Das macht die Lösungspflege einfacher.

Kein standardmäßiger Zugriff auf das SharePoint JavaScript-Objektmodell

Beim Erstellen clientseitiger Anpassungen für die klassische SharePoint-Benutzeroberfläche verwendeten viele Entwickler das JSOM für die Kommunikation mit SharePoint. Das JSOM bot ihnen IntelliSense und einfachen Zugriff auf die SharePoint-API in einer Weise, die dem Client-Side-Objektmodell (CSOM) ähnelt. Auf klassischen SharePoint-Seiten war das Kernstück des JSOM standardmäßig auf der Seite vorhanden, und Entwickler konnten beispielsweise zusätzliche Teile laden, um mit der SharePoint-Suche zu kommunizieren.

In der modernen SharePoint-Benutzeroberfläche ist SharePoint JSOM nicht standardmäßig implementiert. Während Entwickler sie selbst laden können, empfiehlt es sich, stattdessen die REST-API oder die SharePoint Patterns and Practices JavaScript Core Library (PnPJS) zu verwenden, die intern die SharePoint REST-API verwendet. REST ist universeller und lässt sich mit unterschiedlichen clientseitigen Bibliotheken wie jQuery, Angular und React verwenden.

Microsoft investiert nicht aktiv in das JSOM. Wenn Sie es vorziehen, mit einer API zu arbeiten, können Sie die PnP JS-Bibliothek verwenden, die Ihnen eine Fluent-API und TypeScript-Typdeklarationen bietet.

Migrieren vorhandener Anpassungen zu den SharePoint-Framework Erweiterungen

Das Migrieren vorhandener Anpassungen zu den SharePoint-Framework Erweiterungen bietet sowohl Endbenutzern als auch Entwicklern viele Vorteile. Wenn Sie erwägen, vorhandene Anpassungen zum SharePoint-Framework zu migrieren, können Sie entweder so viele der vorhandenen JavaScript-Skripts wie möglich wiederverwenden oder die Anpassung mithilfe von TypeScript vollständig neu schreiben.

Wiederverwenden vorhandener Skripts

Wenn Sie vorhandene Anpassungen zu den SharePoint-Framework Erweiterungen migrieren, können Sie ihre vorhandenen Skripts wiederverwenden. Obwohl das SharePoint-Framework gezielt auf die Verwendung von TypeScript ausgelegt ist, können Sie auch reines JavaScript verwenden und Ihren Code schrittweise auf TypeScript umstellen. Falls Sie eine Lösung nur während eines bestimmten Zeitraums unterstützen müssen oder Ihr Budget begrenzt ist, ist diese Strategie vielleicht ausreichend.

Es ist nicht immer möglich, bereits vorhandene Skripts in einer SharePoint-Framework-Lösung wiederzuverwenden. In Anbetracht der Vielzahl von JavaScript-Bibliotheken lässt sich vorab kaum einschätzen, ob Ihre vorhandenen Skripts in einer gegebenen SharePoint-Framework-Lösung wiederverwendet werden können oder ob Sie sie doch neu schreiben müssen. Sie haben nur die Möglichkeit, die einzelnen Komponenten in eine SharePoint-Framework-Lösung zu überführen und zu testen, ob sie wie erwartet funktionieren.

Neuschreiben der Anpassung

Wenn Sie Ihre Lösung für einen längeren Zeitraum unterstützen müssen oder die SharePoint-Framework besser nutzen möchten oder wenn sich herausstellt, dass Ihre vorhandenen Skripts nicht mit der SharePoint-Framework wiederverwendet werden können, müssen Sie Ihre Anpassung möglicherweise vollständig neu schreiben. Das ist zwar teurer als die Wiederverwendung vorhandener Skripts, führt aber langfristig zu besseren Ergebnissen: einer leistungsfähigeren Lösung, die sich einfacher pflegen und nutzen lässt.

Beim Umschreiben einer vorhandenen Anpassung in eine SharePoint-Framework Lösung sollten Sie mit der gewünschten Funktionalität beginnen. Ziehen Sie zur Implementierung der Benutzeroberfläche Office UI Fabric in Betracht, damit Ihre Lösung wie ein integraler Bestandteil von SharePoint aussieht.

Siehe auch