Migrieren vorhandener Skript-Editor-Webpart-Anpassungen zu SharePoint-Framework
Das SharePoint-Framework ist ein Modell zur Erstellung von SharePoint-Anpassungen. Falls Sie Ihre clientseitigen SharePoint-Lösungen bisher mithilfe des Skript-Editor-Webparts erstellt haben, fragen Sie sich möglicherweise, welche Vorteile eine Migration zum SharePoint-Framework haben könnte.
In diesem Artikel werden die Vorteile einer Migration vorhandener clientseitiger Anpassungen zum SharePoint-Framework beschrieben. Darüber hinaus stellen wir Ihnen verschiedene Aspekte vor, die Sie bei der Migrationsplanung berücksichtigen sollten.
Hinweis
Die Informationen in diesem Artikel gelten für Anpassungen, die mithilfe des Skript-Editor-Webparts erstellt wurden, sowie für Anpassungen, die mithilfe des Inhalts-Editor-Webparts erstellt wurden. Wann immer in diesem Artikel auf das Skript-Editor-Webpart Bezug genommen wird, sind sowohl das Inhalts-Editor-Webpart als auch das Skript-Editor-Webpart gemeint.
Vorteile einer Migration vorhandener clientseitiger Anpassungen zum SharePoint-Framework
Das SharePoint-Framework wurde von Grund auf als ein SharePoint-Entwicklungsmodell konzipiert, das den Schwerpunkt auf die clientseitige Entwicklung legt. Während es in erster Linie Erweiterungsfunktionen für moderne Teamwebsites bietet, funktionieren SharePoint-Framework-basierte Anpassungen auch in der klassischen SharePoint-Oberfläche. Wenn Sie Ihre Anpassungen mit dem SharePoint-Framework erstellen, hat das eine Reihe von Vorteilen gegenüber der Verwendung der übrigen aktuell verfügbaren SharePoint-Entwicklungsmodelle.
Einmal erstellen, geräteunabhängig wiederverwenden
Die moderne SharePoint-Benutzeroberfläche bietet native Unterstützung für den Zugriff auf in SharePoint gespeicherte Informationen, über jedes Gerät. Darüber hinaus unterstützt die moderne Oberfläche auch die mobile SharePoint-App. Lösungen, die mit dem SharePoint-Framework nahtlos in die moderne SharePoint-Benutzeroberfläche integriert werden und können auf verschiedenen Geräten und innerhalb der mobilen SharePoint-App verwendet werden. Da SharePoint-Framework-Lösungen außerdem in der klassischen SharePoint-Oberfläche funktionieren, können sie von Organisationen genutzt werden, die noch nicht zur modernen Oberfläche migriert sind.
Stabiler und zukunftssicher
In der Vergangenheit haben Entwickler SharePoint angepasst, indem sie bestimmte DOM-Elemente in der Benutzeroberfläche anfügen. Mit diesem Ansatz könnten sie die Standardbenutzerfreundlichkeit ändern oder Endbenutzern zusätzliche Funktionen bereitstellen. Solche Lösungen waren jedoch fehleranfällig. Da das DOM der SharePoint-Seite nie als Erweiterbarkeitsoberfläche gedacht war, würden Lösungen, die darauf angewiesen waren, bei jeder Änderung unterbrochen.
SharePoint-Framework bietet Entwicklern standardisierte API- und Erweiterbarkeitspunkte, um clientseitige Lösungen zu erstellen und Endbenutzern zusätzliche Funktionen bereitzustellen. Mit dem SharePoint-Framework haben Entwickler ein Modell zur Erstellung unterstützter und zukunftssicherer Lösungen an der Hand und müssen sich keine Sorgen darüber machen, wie zukünftige Änderungen an der SharePoint-Benutzeroberfläche sich auf ihre Lösung auswirken könnten.
Einfacherer Zugriff auf Informationen in SharePoint und Office 365
Microsoft erweitert den Funktionsumfang von SharePoint und Office 365 kontinuierlich. Da Organisationen beide Plattformen stärker nutzen, wird es für Entwickler immer wichtiger, die in Office 365 gespeicherten Informationen und Erkenntnisse zu nutzen, um umfassende Lösungen zu erstellen. Eines der Ziele von SharePoint Framework ist es, Entwicklern die Anbindung an verschiedenste SharePoint- und Office 365-APIs einfach zu machen.
Anforderungsbasierte Lösungskonfiguration auf Benutzerseite
Clientseitige Lösungen, die über skriptbasierte Einbettung erstellt wurden, boten Endbenutzern häufig keine einfache Möglichkeit, sie ihren Anforderungen anzupassen. Eine Konfiguration solcher Lösungen war nur durch die Anpassung ihres Codes oder über eine speziell für diesen Zweck erstellte individuelle Benutzeroberfläche möglich.
Clientseitige SharePoint Framework-Webparts bieten ein Standardverfahren zur Webpartkonfiguration in Gestalt eines Eigenschaftenbereichs: eine vertraute Funktion für Benutzer, die in der Vergangenheit mit klassischen Webparts gearbeitet haben. Entwickler clientseitiger Webparts können entscheiden, ob ihr Webpart einen dynamischen Eigenschaftenbereich haben soll (Standard), sodass jede Änderung an einer Webparteigenschaft direkt im Webpartkörper sichtbar wird, oder einen nicht dynamischen Eigenschaftenbereich, bei dem Webparteigenschaften explizit angewendet werden müssen.
Unterstützung von No-Script-Websites
Mit der No-Script-Funktion in SharePoint Online möchte Microsoft Organisationen bei der Anpassungsgovernance helfen. Ist für einen Mandanten oder eine bestimmte Websitesammlung das No-Script-Flag gesetzt, werden auf Skriptinjektion und Einbettung basierende Anpassungen deaktiviert.
Da SharePoint-Framework clientseitige Webparts mit vorheriger Genehmigung über den App-Katalog bereitgestellt werden, dürfen sie auf Websites ohne Skripts ausgeführt werden. Auf modernen Teamwebsites ist die No-Script-Einstellung standardmäßig aktiviert, sodass eine Einbettung von Skripts auf diesen Websites nicht möglich ist. Damit ist das SharePoint-Framework das einzige unterstützte Modell zur Erstellung clientseitiger Anpassungen für moderne Teamwebsites.
Ähnlichkeiten zwischen SharePoint-Framework-Lösungen und Skript-Editor-Webpart-Anpassungen
Obwohl sie auf einem neuen Entwicklungsmodell mit einer neuen Toolkette basieren, ähneln SharePoint-Framework Lösungen den Webpartanpassungen des Skript-Editors, die Sie in der Vergangenheit erstellt haben. Die Tatsache, dass beide Anpassungstypen auf dieselben Konzepte setzen, macht eine Migration zum neuen Entwicklungsmodell SharePoint Framework einfacher.
Ausführung als Teil der Seite
Ähnlich wie eingebettete Anpassungen in Skript-Editor-Webparts sind SharePoint-Framework-Lösungen 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.
Im Gegensatz zu SharePoint-Add-Ins sind SharePoint-Framework clientseitigen Webparts nicht in einem iframe isoliert. Ganz gleich also, auf welche Ressourcen ein clientseitiges Webpart zugreifen kann: Die anderen Elemente auf der Seite haben auf diese Ressourcen ebenfalls Zugriff. 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 clientseitige Webparts als Teil der Seite ausgeführt werden, können auch andere Elemente auf dieser Seite auf all diese Ressourcen zugreifen.
Bibliotheksunabhängige Webparterstellung
Bei der Erstellung von Anpassungen mithilfe des Skript-Editor-Webparts 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 clientseitige SharePoint-Framework-Webparts erstellen, können Sie ganz wie bisher auch jede beliebige clientseitige Bibliothek verwenden, um den Funktionsumfang Ihrer Lösung zu erweitern. 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 Webparts 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 Skript-Editor-Webpart-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.
Beschränkung auf clientseitigen Code
Sowohl SharePoint-Framework- als auch Skript-Editor-Webpartlösungen werden im Browser ausgeführt und dürfen nur clientseitigen JavaScript-Code enthalten. Clientseitige Lösungen weisen eine Reihe von Einschränkungen auf, z. B. dass berechtigungen in SharePoint nicht erhöht oder externe APIs erreicht werden, die keine CORS-Unterstützung (Cross-Origin Communication) oder Authentifizierung mithilfe des impliziten OAuth-Flusses unterstützen. In solchen Fällen kann die clientseitige Lösung eine serverseitige Remote-API nutzen, um den erforderlichen Vorgang auszuführen und die Ergebnisse an den Client zurückzugeben.
Lösungshosting in SharePoint
Einer der Vorteile der Erstellung von SharePoint-Anpassungen mithilfe von Skript-Editor-Webparts war die Tatsache, dass der Code in einer normalen SharePoint-Dokumentbibliothek gehostet werden konnte. Verglichen mit SharePoint-Add-Ins war weniger Infrastruktur notwendig, und das Lösungshosting war einfacher. Darüber hinaus konnten Organisationen SharePoint-Berechtigungen verwenden, um den Zugriff auf die Lösungsdateien zu steuern.
Während das Hosting von SharePoint-Framework-Lösungen in einem CDN eine Reihe von Vorteilen hat, ist es nicht zwingend erforderlich. Sie könnten den Lösungscode auch in einer normalen SharePoint-Dokumentbibliothek hosten. SharePoint-Framework Pakete (*.sppkg-Dateien), die im App-Katalog bereitgestellt werden, geben die URL an, unter der SharePoint-Framework den Code der Lösung finden können. Es gibt keine Einschränkungen hinsichtlich des Ziels dieser URL, solange der Benutzer der Seite mit dem Webpart das Skript von dem angegebenen Speicherort herunterladen kann.
Office 365 bietet ein öffentliches CDN, über das Sie Dateien aus einer spezifischen SharePoint-Dokumentbibliothek in einem CDN veröffentlichen können. Das öffentliche CDN von Office 365 ist ein guter Kompromiss zwischen den Vorteilen eines CDN und der Einfachheit des Hostings von Codedateien in einer SharePoint-Dokumentbibliothek. Wenn Ihre Organisation kein Problem darin sieht, Codedateien öffentlich verfügbar zu machen, ist das öffentliche CDN von Office 365 eine interessante Option.
Unterschiede zwischen SharePoint-Framework-Lösungen und Skript-Editor-Webpart-Anpassungen
SharePoint-Anpassungen, die mit dem SharePoint-Framework- und Skript-Editor-Webpart erstellt wurden, sind ähnlich. Beide Anpassungstypen werden als Teil der Seite im Kontext des aktuellen Benutzers ausgeführt und mit clientseitigem JavaScript programmiert. Es gibt aber auch einige wesentliche Unterschiede, die Ihre Architekturentscheidungen beeinflussen könnten und die Sie daher beim Lösungsentwurf berücksichtigen sollten.
Ausführung auf No-Script-Websites
Bei der Erstellung von clientseitigen Anpassungen mithilfe des Skript-Editor-Webparts mussten sie berücksichtigen, ob die Website, auf der die Anpassung eingesetzt werden sollte, eine No-Script-Website war oder nicht. War die Website eine No-Script-Website, mussten Sie entweder den Administrator bitten, die No-Script-Einstellung zu deaktivieren, oder Ihre Lösung umgestalten, beispielsweise durch eine Umstellung auf das Add-In-Modell.
Da SharePoint-Framework-Lösungen über den App-Katalog bereitgestellt und vorab genehmigt werden, fallen sie nicht unter die No-Script-Einschränkungen und funktionieren auf allen Websites.
Bereitstellung und Aktualisierung durch die IT-Abteilung
Skript-Editor-Webparts werden vor allem von sogenannten Citizen Developers zur Erstellung von SharePoint-Anpassungen genutzt. Auch wenn sie nur mit Websitebesitzerberechtigungen ausgestattet sind, können Citizen Developer attraktive SharePoint-Anpassungen erstellen, die konkreten geschäftlichen Mehrwert bieten. Wenn die Anpassung aktualisiert werden soll, können Benutzer mit den erforderlichen Berechtigungen Updates auf die Skriptdateien der Lösung anwenden, und die Änderungen sind sofort für alle Benutzer sichtbar.
Skript-Editor-Webpartlösungen machen es IT-Organisationen schwer, nachzuverfolgen, welche Anpassungen verwendet werden und wo sie verwendet werden. Darüber hinaus hat sie keine Möglichkeit, festzustellen, welche externen Skripts in ihrem Intranet verwendet werden und Zugriff auf ihre Daten haben.
SharePoint Framework gibt der IT-Abteilung die Kontrolle zurück. Da SharePoint Framework-Lösungen zentral im App-Katalog bereitgestellt und verwaltet werden, kann sie jede Lösung vor der Bereitstellung prüfen. Darüber hinaus werden auch alle Updates über den App-Katalog bereitgestellt, sodass auch sie vor der Bereitstellung überprüft und genehmigt werden können.
Verstärkter Fokus auf einer einheitlichen Benutzeroberfläche
Bei der Erstellung von Anpassungen mithilfe des Skript-Editor-Webparts hatten Citizen Developer die Kontrolle über das gesamte DOM ihrer Anpassung. Es gab keine Richtlinien hinsichtlich der Benutzeroberfläche oder der Funktionsweise von Anpassungen. Im Ergebnis erstellte jeder Entwickler seine Anpassungen anders, und die Endbenutzer waren mit vielen unterschiedlichen Benutzeroberflächen konfrontiert.
Eines der Ziele des SharePoint-Framework ist die Standardisierung der Erstellung clientseitiger Anpassungen. Es soll Einheitlichkeit erreicht werden, von der Bereitstellung über die Pflege bis hin zur Benutzeroberfläche. Mithilfe von Office UI Fabric können Entwickler ihre benutzerdefinierten Lösungen leichter so gestalten, dass sie im Hinblick auf visuelles Design und Verhalten wie ein integraler Bestandteil von SharePoint wirken. Das fördert die Akzeptanz auf Benutzerseite. Die SharePoint-Framework-Toolkette generiert Paketdateien für die Lösungen, die im App-Katalog bereitgestellt werden, sowie Skriptbundles, die an einem frei wählbaren Hostingspeicherort bereitgestellt werden. Aufbau und Verwaltungsprozess sind bei jeder Lösung gleich.
Keine DOM-Modifizierung außerhalb der Anpassung
In der Vergangenheit wurden Skript-Editor-Webparts häufig eingesetzt, um Teile einer Seite zu ändern, so beispielsweise um die Symbolleiste um zusätzliche Schaltflächen zu erweitern oder die Überschrift oder das Branding der Seite anzupassen. Solche Anpassungen waren von bestimmten DOM-Elementen abhängig; bei jeder Aktualisierung der SharePoint-Benutzeroberfläche bestand daher ein Risiko, das sie anschließend nicht mehr funktionierten.
Das SharePoint-Framework fördert eine strukturierte und zuverlässige Vorgehensweise bei der Anpassung von SharePoint. Statt spezifische DOM-Elemente zur Anpassung von SharePoint zu verwenden, gibt SharePoint Framework Entwicklern eine öffentliche API an die Hand, mit deren Hilfe sie SharePoint erweitern können. Das SharePoint-Framework unterstützt als Form ausschließlich clientseitige Webparts. Die zukünftige Implementierung von Unterstützung für weitere Formen wie beispielsweise JSLink-Äquivalenten und benutzerdefinierten Benutzeraktionen wird aktuell geprüft. Ziel ist es, dass Entwickler mit dem SharePoint-Framework die gängigsten Anpassungsszenarien implementieren können.
Verteilung im Paketformat
Clientseitige SharePoint-Anpassungen verwenden zur Speicherung ihrer Daten häufig SharePoint-Listen und -Bibliotheken. Bei der Erstellung mit dem Skript-Editor-Webpart gab es keine einfache Möglichkeit, die erforderlichen Voraussetzungen automatisch bereitzustellen. Sollte eine Anpassung auch auf einer anderen Website bereitgestellt werden, musste häufig nicht nur das Webpart kopiert, sondern auch der benötigte Datenspeicher korrekt neu erstellt und gepflegt werden.
SharePoint-Framework Lösungen werden verteilt, da Pakete ihre Voraussetzungen wie Felder, Inhaltstypen oder Listen automatisch bereitstellen können. Entwickler können bei der Erstellung des Pakets angeben, welche Artefakte die Lösung erfordert; wann immer die Lösung dann auf einer Website installiert wird, werden die betreffenden Artefakte erstellt. Dadurch wird es deutlich einfacher, die Lösung auf mehreren Websites bereitzustellen und zu verwalten.
Verwendung von TypeScript für stabilere und einfacher zu pflegende Lösungen
Bei der Erstellung von Script-Editor-Webpart-Anpassungen haben Citizen Developer 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.
Keine Unterstützung für das spPageContextInfo-Objekt
In der Vergangenheit nutzten Entwickler bei der Erstellung wiederverwendbarer clientseitiger Anpassungen das JavaScript-Objekt spPageContextInfo, um Informationen über die aktuelle Seite, die aktuelle Website oder den aktuellen Benutzer abzurufen. Dieses Objekt bot eine einfache Möglichkeit, die Lösung auf mehreren SharePoint-Websites wiederzuverwenden und feste URLs zu vermeiden.
Doch obwohl das Objekt spPageContextInfospPageContextInfo auf klassischen SharePoint-Seiten noch im Einsatz ist, lässt es sich mit modernen SharePoint-Seiten und -Bibliotheken nicht zuverlässig verwenden. Entwicklern von SharePoint-Framework-Lösungen empfehlen wir stattdessen die Verwendung des Objekts [IWebPartContext.pageContext](/javascript/api/sp-webpart-base/iwebpartcontext), das die Kontextinformationen der jeweiligen Lösung enthält.
Kein standardmäßiger Zugriff auf das SharePoint JavaScript-Objektmodell
Bei der Erstellung clientseitiger Anpassungen für die klassische SharePoint-Benutzeroberfläche verwendeten viele Entwickler das JavaScript-Objektmodell (JSOM) zur Kommunikation mit SharePoint. JSOM bot IntelliSense und einfachen Zugriff auf die SharePoint-API, ähnlich wie das clientseitige Objektmodell (CSOM). Auf klassischen SharePoint-Seiten war die Kernkomponente von JSOM standardmäßig implementiert, und Entwickler konnten zusätzliche Komponenten laden, beispielsweise zur Kommunikation mit der SharePoint-Suche.
In der modernen SharePoint-Benutzeroberfläche ist SharePoint JSOM nicht standardmäßig implementiert. Zwar können Entwickler es selbst laden, doch empfehlen wir stattdessen die Verwendung der REST-API. REST ist universeller und lässt sich mit unterschiedlichen clientseitigen Bibliotheken wie jQuery, Angular und React verwenden.
Microsoft investiert nicht mehr aktiv in JSOM. Wenn Sie die Arbeit mit einer API bevorzugen, können Sie stattdessen die SharePoint Patterns and Practices JavaScript Core Library verwenden, die eine Fluent-API sowie TypeScript-Typisierungen bietet.
Migrieren vorhandener Anpassungen zum SharePoint-Framework
Eine Migration vorhandener Skript-Editor-Webpart-Anpassungen zum SharePoint-Framework hat sowohl für Endbenutzer als auch für Entwickler Vorteile. Wenn Sie die Migration vorhandener Anpassungen zum SharePoint-Framework in Betracht ziehen, können Sie entweder so viele der vorhandenen Skripts wie möglich wiederverwenden oder die Anpassung vollständig neu schreiben.
Wiederverwenden vorhandener Skripts
Wenn Sie vorhandene Skript-Editor-Webpart-Anpassungen zum SharePoint-Framework migrieren, können Sie Ihre bereits 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. SharePoint-Framework-Lösungen werden beispielsweise als JavaScript-Module verpackt und laden asynchron auf der Seite. Einige JavaScript-Bibliotheken funktionieren aber nicht einwandfrei, wenn sie in einem Modul referenziert werden, oder müssen auf eine bestimmte Art und Weise referenziert werden. Darüber hinaus können die Einbindung von Seitenereignissen wie onload() oder der Einsatz der jQuery-Funktion ready() zu unerwünschten Ergebnissen führen.
Angesichts der Vielzahl von JavaScript-Bibliotheken gibt es keine einfache Möglichkeit, vorab zu ermitteln, ob Ihre vorhandenen Skripts in einer SharePoint-Framework-Lösung wiederverwendet werden können oder ob Sie sie doch umschreiben 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, die SharePoint-Framework besser nutzen möchten oder wenn sich herausstellt, dass Ihre vorhandenen Skripts nicht mit dem 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.
Bei der Umschreibung einer vorhandenen Skript-Editor-Webpart-Anpassung in eine SharePoint-Framework-Lösung sollten Sie immer von der gewünschten Funktion ausgehen. Ziehen Sie zur Implementierung der Benutzeroberfläche Office UI Fabric in Betracht, damit Ihre Lösung wie ein integraler Bestandteil von SharePoint aussieht. Für die Realisierung von spezifischen Komponenten wie Diagrammen oder Schiebereglern sollten Sie auf moderne Bibliotheken zurückgreifen, die als Modul verteilt werden und über TypeScript-Typisierungen verfügen. Das macht es einfacher, die Komponenten in die Lösung zu integrieren.
Es gibt zwar keine allgemeingültige Antwort auf die Frage, welche Komponente für welches Szenario am besten geeignet ist; das SharePoint-Framework ist jedoch flexibel genug, um die meisten gängigen Szenarien unterstützen zu können. Mithilfe dieses Modells können Sie Ihre vorhandenen clientseitigen Anpassungen in SharePoint-Framework-Lösungen mit vollem Funktionsumfang überführen.
Tipps für die Migration
Bei der Umgestaltung vorhandener Skript-Editor-Webpart-Anpassungen in SharePoint-Framework-Anpassungen gibt es einige häufige Muster.
Überführen des vorhandenen Codes zum SharePoint-Framework
SharePoint-Anpassungen auf Basis des Skript-Editor-Webparts bestehen oft aus in das Webpart integriertem HTML-Markup und einem oder mehreren Verweisen auf JavaScript-Dateien. Wenn Sie eine vorhandene Anpassung in eine SharePoint-Framework-Lösung überführen, müssen Sie das HTML-Markup aus dem Skript-Editor-Webpart höchstwahrscheinlich in die Methode render() des clientseitigen SharePoint-Framework-Webparts verschieben. Verweise auf externe Skripts müssen in Verweise in der Eigenschaft externals in der Datei ./config/config.json umgeändert werden. Interne Skripts müssen Sie in den Quellordner des Webparts kopieren und mithilfe von Anweisungen des Typs require() aus der Webpartklasse referenzieren.
Referenzieren von Funktionen aus Skriptdateien
Zur Referenzierung von Funktionen aus Skriptdateien müssen Sie die Funktionen als Export definieren. Nehmen wir als Beispiel eine bereits vorhandene JavaScript-Datei, die Sie in einem clientseitigen SharePoint-Framework-Webpart verwenden möchten:
var greeting = function() {
alert('How are you doing?');
return false;
}
Um die Funktion greeting aus der Webpartklasse aufzurufen, müssen Sie die JavaScript-Datei wie folgt ändern:
var greeting = function() {
alert('How are you doing?');
return false;
}
module.exports = {
greeting: greeting
};
Anschließend können Sie in der Webpartklasse auf das Skript verweisen und die Funktion greeting aufrufen:
public render(): void {
this.domElement.innerHTML = `<input type="button" value="Click me"/>`;
const myScript = <any> require('./my-script.js');
this.domElement.querySelector('input').addEventListener('click', myScript.greeting);
}
Ausführen von AJAX-Aufrufen
Viele clientseitige Anpassungen verwenden jQuery zur Ausführung von AJAX-Anforderungen, aufgrund seiner Einfachheit und seiner browserübergreifenden Kompatibilität. Falls Sie jQuery nur dafür verwenden: Sie können AJAX-Aufrufe auch über den Standard-HTTP-Client des SharePoint-ramework ausführen.
SharePoint Framework bietet zwei Typen von HTTP-Clients: SPHttpClient zur Ausführung von Anforderungen an die SharePoint-REST-API und HttpClient zur Ausgabe von Webanforderungen an andere REST-APIs. Einen Aufruf mit SPHttpClient zum Abrufen des Titels der aktuellen SharePoint-Website würden Sie wie folgt ausführen:
this.context.spHttpClient.get(`${this.context.pageContext.web.absoluteUrl}/_api/web?$select=Title`,
SPHttpClient.configurations.v1,
{
headers: {
'Accept': 'application/json;odata=nometadata',
'odata-version': ''
}
})
.then((response: SPHttpClientResponse): Promise<{Title: string}> => {
return response.json();
})
.then((web: {Title: string}): void => {
// web.Title
}, (error: any): void => {
// error
});