SPFx avant la version 1.0 : 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. Quatre de nos web parts se trouvent aujourd'hui dans ce dépôt, à la portée de qui veut les lire, et Microsoft les répertorie toutes les quatre à notre nom dans sa Sample Solution Gallery. La plus récente a été intégrée le 3 août 2026, le jour même où deux des anciennes ont été réintégrées après avoir été réécrites. 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.

Microsoft 365 Search Hub

Cherche des documents, des pages, des sites et des éléments de liste via la Microsoft Search API dans Microsoft Graph, depuis une seule zone de saisie, et indique pour chaque résultat où il vit et qui l'a modifié en dernier. SPFx 1.23.2, chaîne de build Heft, Fluent UI v9.

SharePoint a déjà une excellente recherche et celle-ci ne cherche pas à la remplacer. Elle sert au cas où la recherche livrée d'origine ne convient pas au problème : une page où chercher a sa place parmi les autres choses de cette page, plutôt que d'envoyer la personne vers un centre de recherche en lui retirant le contexte où elle se trouvait, ou un portail où seul un certain ensemble de sites mérite d'être fouillé.

La zone de recherche est la partie la moins intéressante. Ce qui mérite d'être lu se trouve dessous : tenir séparés le service, la session et l'interface, pour que la concurrence vive à un seul endroit au lieu d'être répartie dans les composants ; distinguer une permission refusée d'une session expirée, du throttling, d'un service qui a un mauvais jour, car chacun de ces cas demande des mots différents à l'écran ; et tester le debounce, les réponses dépassées, un cache court et la pagination, courses comprises, sans moteur de rendu.

Et là où elle s'arrête, elle s'arrête exprès. Les personnes, les messages Teams, le courrier et le calendrier sont chacun un type d'entité distinct dans la Search API, chacun avec sa permission et sa requête. En ajouter un est un autre sample, pas une version plus grande de celui-ci, et le dire dans le README fait partie du sample.

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. Porter un sample vers l'avant est le même travail que porter vers l'avant la web part d'un client, et cela laisse une trace : le 3 août 2026, le calculateur et la web part des jours fériés ont tous deux été réintégrés après réécriture, et le sample le plus récent est entré directement en 1.23.2. 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.