SPFx vor Version 1.0: drei unserer Web Parts in den offiziellen Microsoft-Samples

Die Developer Preview des SharePoint Framework erschien im August 2016. Version 1.0.0 wurde am 22. Februar 2017 allgemein verfügbar.

Unser erster Beitrag zu pnp/sp-dev-fx-webparts, dem offiziellen Sample-Repository der Microsoft-365-Community, wurde am 6. Oktober 2016 übernommen. Fünf Monate bevor es eine 1.0 gab, auf der man bauen konnte.

Das ist der Teil eines Werdegangs, den man nicht nachträglich behaupten kann. Drei unserer Web Parts liegen heute in diesem Repository, für jeden lesbar. Dies ist der Zweck jeder einzelnen.

Eine Northwind-Datenbank über eine Azure Function nutzen

Eine SharePoint-Seite braucht Daten, die nicht in SharePoint liegen. Der Instinkt greift direkt zur Datenbank, und dieser Instinkt ist teuer: Er stellt eine Verbindungszeichenfolge vor den Browser, bindet die Seite an ein Schema und macht jede künftige Schemaänderung zu einer Änderung der Seite.

Diese Web Part ruft einen anonymen HTTP-Trigger in einer Azure Function App auf und stellt dar, was zurückkommt. Die Web Part weiß nie, dass es eine Datenbank gibt. Sie weiß, dass es einen Endpunkt gibt, und der Endpunkt entscheidet, was die Frage bedeutet und wer sie stellen darf.

Sie ist bewusst unspektakulär, und sie ist die Form, die wir in Kundenprojekten verwenden, wenn SharePoint etwas zeigen soll, das einem anderen System gehört. Die interessante Ingenieursarbeit steckt nicht in der Web Part. Sie steckt in der Grenze.

Carbon Footprint Calculator

Ein interaktiver Rechner, der den monatlichen CO2-Fußabdruck aus Strom, Verkehr, Heizung und Wasser schätzt, das Ergebnis nach Quelle aufschlüsselt und als PDF exportiert. React, Fluent UI und Chart.js.

Wir haben ihn gebaut, weil wir einen für unsere eigene Nachhaltigkeitsberichterstattung brauchten, und die ehrlichen Optionen waren eine Tabelle, die niemand öffnete, oder eine externe Seite, die die Zahlen dorthin mitnahm, wo wir sie nicht mehr sahen. Als Web Part verlassen die Daten nie den Tenant. Diese Einschränkung erklärt seine Form.

Er ist zugleich eine funktionierende Antwort auf eine Frage, die uns oft gestellt wird: ob ein internes Werkzeug wirklich nützlich sein kann, ohne zu einem weiteren zu pflegenden System zu werden. Dieses hier ist eine Web Part auf einer Seite. Keine Datenbank, kein Dienst, keine eigene Anmeldung, und später nichts abzubauen.

Public Holidays Global

Zeigt die Feiertage eines gewählten Landes und Jahres, mit Blätterfunktion und Diagramm, und liest live aus der öffentlichen API Nager.Date.

Sie entstand aus einem gewöhnlichen Ärgernis in einer Organisation mit Menschen in mehr als einem Land: Die Antwort darauf, wer nächsten Dienstag fehlt, lebt im Kopf einer Person oder in einer Liste, die im März aufgehört hat, gepflegt zu werden. Die Daten gibt es bereits und ihre Abfrage ist kostenlos.

Die Web Part ist bewusst dünn. Sie speichert nichts, denn ein gespeicherter Feiertagskalender veraltet still und wird trotzdem weiter geglaubt. Ändert sich die Länderliste im nächsten Jahr, muss sich niemand daran erinnern, etwas nachzuziehen.

Warum sie öffentlich sind

Weil eine Behauptung über Kompetenz weniger wert ist als die Möglichkeit, sie zu prüfen.

Wer entscheidet, ob er mit uns an SharePoint arbeitet, kann den Code lesen, statt uns aufs Wort zu glauben. Er kann sehen, wie wir mit einer fremden API umgehen, wo wir die Grenze zwischen Seite und Daten ziehen, was wir mit Versionen und Kompatibilität machen, und ob das Ganze baut. Das ist eine stärkere Aussage als eine Beschreibung unserer Erfahrung, und die Prüfung kostet die lesende Person nichts.

Es gibt einen zweiten Grund, der intern mehr zählt. Samples in diesem Repository werden gegen Beitragsregeln validiert und von Menschen gelesen, die tausende gesehen haben. Dort zu veröffentlichen heißt, dass unsere SPFx-Arbeit von Leuten geprüft wird, die keinen Anlass haben, freundlich zu sein.

Worum es hier wirklich geht

SPFx steht bei Version 1.23 und hat ein Jahrzehnt aus Node-Versionen, Build-Ketten, React-Hauptversionen und Abkündigungen hinter sich. Der größte Teil der Schwierigkeit eines SharePoint-Frontends war nie das Framework. Es ist zu wissen, welche Teile stabil genug sind, um darauf das System eines Kunden zu bauen, und welche in zwei Jahren verschwunden sein werden.

Dieses Urteil kommt daher, bei den Versionen dabei gewesen zu sein, die es nicht mehr gibt. Wir haben diese Samples durch jene Zyklen getragen, und wir haben darüber geschrieben, was das in der Praxis kostet, in SPFx 1.23.2: aktualisieren ist nicht eine Nummer ändern und in der Stand von SharePoint 2026.

Wenn Sie auf SharePoint bauen und das Frontend von Leuten wollen, die schon vor Version 1.0 dabei waren, sprechen Sie mit uns. Der Code ist öffentlich. Fangen Sie mit dem Lesen an.