SPFx avant la version 1.0 : trois de nos web parts dans les samples officiels de Microsoft

La developer preview du SharePoint Framework est sortie en août 2016. La version 1.0.0 est devenue disponible le 22 février 2017.

Notre première contribution à pnp/sp-dev-fx-webparts, le dépôt officiel des samples de la communauté Microsoft 365, a été intégrée le 6 octobre 2016. Cinq mois avant qu'il existe une 1.0 sur laquelle construire.

C'est la partie d'un parcours qui ne se revendique pas après coup. Trois de nos web parts se trouvent aujourd'hui dans ce dépôt, à la portée de qui veut les lire. Voici à quoi sert chacune.

Consommer une base Northwind via une Azure Function

Une page SharePoint a besoin de données qui ne vivent pas dans SharePoint. L'instinct est d'aller directement à la base, et cet instinct coûte cher : il place une chaîne de connexion devant le navigateur, arrime la page à un schéma, et transforme chaque évolution future de ce schéma en évolution de la page.

Cette web part appelle un déclencheur HTTP anonyme sur une Azure Function App et affiche ce qui revient. La web part ne sait jamais qu'il existe une base de données. Elle sait qu'il existe un point d'entrée, et c'est ce point d'entrée qui décide du sens de la question et de qui a le droit de la poser.

C'est volontairement sans éclat, et c'est la forme que nous employons chez nos clients quand SharePoint doit montrer une chose qui appartient à un autre système. L'ingénierie intéressante n'est pas dans la web part. Elle est à la frontière.

Carbon Footprint Calculator

Un calculateur interactif qui estime l'empreinte carbone mensuelle à partir de l'électricité, des transports, du chauffage et de l'eau, décompose le résultat par origine, et l'exporte en PDF. React, Fluent UI et Chart.js.

Nous l'avons construit parce qu'il nous en fallait un pour notre propre reporting de durabilité, et les options honnêtes étaient un tableur que personne n'ouvrait ou un site externe qui emportait les chiffres là où nous ne les voyions plus. En web part, les données ne quittent jamais le tenant. C'est cette contrainte qui explique sa forme.

C'est aussi une réponse qui fonctionne à une question qu'on nous pose souvent : un outil interne peut-il être vraiment utile sans devenir un système de plus à maintenir. Celui-ci est une web part sur une page. Pas de base de données, pas de service, pas d'authentification à part, et rien à démanteler plus tard.

Public Holidays Global

Affiche les jours fériés d'un pays et d'une année au choix, avec pagination et graphique, en lisant en temps réel l'API publique Nager.Date.

Elle est née d'un agacement ordinaire dans une organisation répartie sur plusieurs pays : la réponse à qui est absent mardi prochain vit dans la tête de quelqu'un, ou dans une liste qui a cessé d'être tenue en mars. Les données existent déjà et s'interrogent gratuitement.

La web part est volontairement mince. Elle ne stocke rien, car un calendrier de jours fériés stocké est une chose qui se périme en silence et à laquelle on continue de faire confiance. Si la liste des pays change l'an prochain, personne n'a à se souvenir de mettre quoi que ce soit à jour.

Pourquoi elles sont publiques

Parce qu'une affirmation sur la compétence vaut moins que la possibilité de la vérifier.

Qui décide de travailler avec nous sur SharePoint peut lire le code plutôt que nous croire sur parole. Il peut voir comment nous traitons une API tierce, où nous plaçons la frontière entre la page et les données, ce que nous faisons des versions et de la compatibilité, et si cela compile. C'est une affirmation plus forte qu'une description de notre expérience, et la vérifier ne coûte rien au lecteur.

Il y a une seconde raison, qui compte davantage en interne. Les samples de ce dépôt sont validés contre des règles de contribution et lus par des personnes qui en ont vu des milliers. Publier là signifie que notre travail SPFx est relu par des gens qui n'ont aucune raison d'être aimables.

De quoi il s'agit vraiment

SPFx en est à la version 1.23 et a traversé une décennie de versions de Node, de chaînes de build, de versions majeures de React et de dépréciations. L'essentiel de la difficulté d'un front end SharePoint n'a jamais été le framework. C'est de savoir quelles parties sont assez stables pour y bâtir le système d'un client, et quelles parties auront disparu dans deux ans.

Ce jugement vient d'avoir été présent aux versions qui n'existent plus. Nous avons porté ces samples à travers ces cycles, et nous avons écrit sur ce que cela coûte en pratique, dans SPFx 1.23.2 : mettre à jour n'est pas changer un numéro et dans l'état de SharePoint en 2026.

Si vous construisez sur SharePoint et souhaitez un front end réalisé par des gens qui étaient là avant la version 1.0, parlez-nous. Le code est public. Commencez par le lire.