Über unsLeistungenProjekteR&DBlogWerkzeugeAnfangenKontakt

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

Die Developer Preview des SharePoint Framework erschien im August 2016. Version 1.0 kam im Februar 2017. Unser erster Beitrag zum offiziellen Sample-Repository von Microsoft 365 stammt vom Oktober 2016, fünf Monate bevor es eine 1.0 gab, auf der man bauen konnte. Vier unserer Web Parts liegen heute in diesem Repository, und dies ist der Zweck jeder einzelnen.

pH7x Systems® · ·aktualisiert am · 6 Min. Lesezeit

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. Vier unserer Web Parts liegen heute in diesem Repository, für jeden lesbar, und Microsoft führt alle vier unter unserem Namen in seiner Sample Solution Gallery. Die neueste wurde am 3. August 2026 übernommen, am selben Tag, an dem zwei der älteren nach einer Überarbeitung erneut übernommen wurden. Dies ist der Zweck jeder einzelnen.

Die Northwind-Web-Part zeigt Daten, die eine Azure Function App zurückgibt, innerhalb einer SharePoint-Seite Der Carbon Footprint Calculator: Eingaberegler für Strom, Flüge, Autofahrten, Gas und Wasser, mit den Emissionen pro Person als waagerechtes Balkendiagramm und einer Schaltfläche für den PDF-Export Die Web Part Public Holidays Global zeigt eine seitenweise Liste der Feiertage für ein gewähltes Land und Jahr, mit einem Diagramm, das sie nach Monat zusammenfasst Die Web Part Microsoft 365 Search Hub zeigt die Treffer zu einem Wort in Dokumenten, Seiten, Sites und Listenelementen, jeder Treffer mit der Site, auf der er liegt, und wer ihn zuletzt geändert hat

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.

Microsoft 365 Search Hub

Sucht Dokumente, Seiten, Sites und Listenelemente über die Microsoft Search API in Microsoft Graph, aus einem einzigen Feld, und nennt zu jedem Treffer, wo er liegt und wer ihn zuletzt geändert hat. SPFx 1.23.2, Heft-Build-Kette, Fluent UI v9.

SharePoint hat bereits eine ausgezeichnete Suche, und diese versucht nicht, sie zu ersetzen. Sie ist für den Fall gedacht, dass die mitgelieferte Suche nicht zum Problem passt: eine Seite, auf der das Suchen zwischen die übrigen Dinge dieser Seite gehört, statt die Person in ein Suchcenter zu schicken und ihr den Zusammenhang zu nehmen, in dem sie war, oder ein Portal, in dem nur eine bestimmte Menge von Sites überhaupt durchsucht werden soll.

Das Suchfeld ist der am wenigsten interessante Teil. Lesenswert ist, was darunter liegt: Dienst, Sitzung und Oberfläche getrennt zu halten, damit die Nebenläufigkeit an einer Stelle wohnt statt über die Komponenten verteilt zu sein; eine verweigerte Berechtigung von einer abgelaufenen Anmeldung, von Throttling, von einem Dienst mit einem schlechten Tag zu unterscheiden, weil jeder dieser Fälle andere Worte auf dem Bildschirm braucht; und Debounce, überholte Antworten, einen kurzen Cache und die Blätterfunktion zu testen, Wettläufe eingeschlossen, ohne Renderer.

Und wo sie aufhört, hört sie mit Absicht auf. Personen, Teams-Nachrichten, E-Mail und Kalender sind in der Search API jeweils ein eigener Entitätstyp, jeder mit eigener Berechtigung und eigener Anfrage. Einen davon aufzunehmen ist ein anderes Sample, keine größere Fassung dieses einen, und das im README zu sagen gehört zum Sample.

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. Ein Sample weiterzutragen ist dieselbe Arbeit wie die Web Part eines Kunden weiterzutragen, und sie hinterlässt eine Spur: Am 3. August 2026 wurden der Rechner und die Feiertags-Web-Part nach ihrer Überarbeitung beide erneut übernommen, und das neueste Sample kam gleich in 1.23.2 hinein. 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.

Kommentare

Weiterlesen