Migration des actions personnalisées de l’utilisateur et des éléments de menu BCE vers les extensions de SharePoint Framework
Le SharePoint Framework (SPFx) est le modèle de développement recommandé pour l’extension et la création de personnalisations SharePoint. Si vous avez personnalisé SharePoint avec des actions personnalisées utilisateur et des éléments de menu Edit Control Block (ECB) personnalisés à l’aide de SharePoint Feature Framework, vous vous demandez peut-être quel est l’avantage de les migrer vers SPFx ?
Tout d’abord, nous allons présenter les options disponibles lors du développement d’extensions SharePoint Framework (SPFx) :
- Personnalisateur d’application : étend l’IU native « moderne » de SharePoint en ajoutant des éléments HTML personnalisés et du code côté client à des espaces réservés prédéfinis dans les pages « modernes ». Pour plus d’informations sur les personnalisateurs d’application, consultez Créer votre première extension SharePoint Framework (Hello World 1re partie).
- Jeu de commandes : ajoutez des éléments de menu BCE personnalisés ou des boutons personnalisés à la barre de commandes d’un affichage de liste pour une liste ou une bibliothèque. Vous pouvez associer n’importe quelle action côté client à ces commandes. Pour plus d’informations sur les jeux de commandes, consultez Créer votre première extension de jeu de commandes ListView.
- Personnalisateur de champ : personnalisez le rendu d’un champ dans un affichage de liste à l’aide d’éléments HTML personnalisés et de code côté client. Pour plus d’informations sur les personnalisateurs de champ, consultez Créer votre première extension de personnalisateur de champ.
Selon la cible de votre personnalisation, vous pouvez tirer parti des avantages offerts par les versions ci-dessus. Par exemple, les personnalisateurs d’application peuvent remplacer les actions personnalisées de l’utilisateur. Les jeux de commandes remplacent les éléments de menu ECB. Enfin, les personnalisateurs de champ sont destinés à remplacer les personnalisations JSLink/Client-Side-Rendering (CSR).
Avantages de la migration de personnalisations SharePoint Feature Framework existantes vers SharePoint Framework
Nous avons développé SharePoint Framework en gardant à l’esprit la nouvelle expérience « moderne » de SharePoint disponible dans les sites d’équipe et de communication « modernes », qui s’applique à tous les appareils et à toutes les plateformes.
Seul moyen pris en charge de la personnalisation des sites « modernes » sans script
L’un des principaux avantages de la migration des personnalisations héritées de SharePoint Feature Framework vers le SharePoint Framework est qu’il s’agit de la seule technique prise en charge que vous avez sur les sites modernes pour personnaliser l’interface utilisateur.
En fait, les sites « modernes » ont l’indicateur no-script activé, ce qui évite d’exécuter des scripts incorporés dans la page, et toute action personnalisée de l’utilisateur, qui fait référence à JavaScript externe ou à JavaScript incorporé.
Les actions personnalisées de l’utilisateur hérité ne fonctionnent tout simplement pas dans l’interface utilisateur « moderne ». Les personnalisations ECB générées à l’aide de Feature Framework sont limitées. Vous pouvez uniquement définir des éléments BCE qui ne font pas référence à des fichiers JavaScript externes ou qui n’utilisent pas d’appels JavaScript incorporés. Si vous souhaitez vraiment étendre l’interface utilisateur « moderne », vous devez effectuer une mise à niveau vers le SharePoint Framework.
Accès plus facile aux informations dans SharePoint et Microsoft 365
Un autre point fondamental à prendre en compte est que dans le modèle hérité d’actions personnalisées utilisateur et de personnalisations ECB, il n’était pas facile de consommer du contenu et des données SharePoint. La seule solution était d’utiliser JSOM (le modèle objet côté client JavaScript de SharePoint) ou des API REST de bas niveau. En outre, il était presque impossible de consommer l’ensemble complet des services de Microsoft 365, sauf si vous avez tiré parti de manière autonome ADAL.JS (bibliothèque d’authentification Azure Active Directory pour JavaScript) et du code JavaScript personnalisé.
Désormais, avec l’SharePoint Framework et les extensions SharePoint Framework, il est facile et simple d’utiliser l’API REST SharePoint et Microsoft Graph. Vous pouvez désormais créer des solutions plus puissantes, qui peuvent consommer et interagir avec l’écosystème complet des services fournis par Microsoft 365.
Similarités entre les solutions SharePoint Framework et les personnalisations SharePoint Feature Framework
Les actions personnalisées de l’utilisateur sharePoint Feature Framework et les éléments BCE et les personnalisations sharePoint Feature Framework partagent certaines similitudes.
Modèle de mise en service
Les extensions SharePoint Framework et les actions personnalisées de l’utilisateur ou les solutions d’éléments de menu BCE utilisent un fichier manifeste XML, qui est écrit avec la syntaxe SharePoint Feature Framework ; le déploiement est basé sur les mêmes techniques.
Exécution en tant qu’une partie de la page
Tout comme les actions personnalisées de l’utilisateur et les éléments de menu BCE de SharePoint Feature Framework, les extensions de SharePoint Framework font partie de la page. Ainsi, ces solutions ont accès au DOM de la page et peuvent communiquer avec d’autres composants sur la même page. En outre, cela permet aux développeurs d’adapter plus facilement leurs solutions aux différents facteurs de forme sur lesquels une page SharePoint peut être affichée, y compris l’application mobile SharePoint.
Étant donné que les extensions de SharePoint Framework sont exécutées comme une partie de la page, les autres éléments de la page peuvent accéder aux mêmes ressources que la personnalisation. Il est important de garder cela à l’esprit lors de la création de solutions qui reposent sur un flux implicite OAuth avec des jetons d’accès de support, ou qui utilisent des cookies ou le stockage du navigateur pour stocker des informations sensibles. Étant donné que les extensions de SharePoint Framework sont exécutées comme une partie de la page, les autres éléments de la page peuvent également accéder à l’ensemble de ces ressources.
Création des extensions à l’aide de la bibliothèque de votre choix
Lorsque vous créez des personnalisations de page à l’aide d’actions personnalisées utilisateur, vous avez peut-être utilisé des bibliothèques telles que jQuery ou Knockout pour implémenter des personnalisations dynamiques et mieux répondre à l’interaction utilisateur. Quand vous créez des extensions de SharePoint Framework, vous pouvez utiliser n’importe quelle bibliothèque côté client pour enrichir votre solution, comme vous l’auriez fait auparavant.
Un autre avantage que la SharePoint Framework offre est l’isolation de votre script. Même si le composant WebPart est exécuté dans le cadre de la page, son script est empaqueté sous la forme d’un module permettant à différentes extensions sur la même page d’utiliser une version différente de jQuery sans entrer en conflit les unes avec les autres. Cette fonction avancée vous permet de vous concentrer sur la valeur commerciale plutôt que sur des migrations techniques sans faire de compromis sur les fonctionnalités.
Exécution en tant qu’utilisateur actuel
Dans les personnalisations créées à l’aide des actions personnalisées de l’utilisateur et des éléments de menu BCE, il vous suffisait d’appeler les API de SharePoint quand vous aviez besoin de communiquer avec ce dernier. La solution côté client s’exécutait dans le navigateur dans le contexte de l’utilisateur actuel et, en envoyant automatiquement le cookie d’authentification avec la demande, votre solution pouvait se connecter directement à SharePoint. Aucune autre authentification supplémentaire (comme lors de l’utilisation de compléments SharePoint) n’était nécessaire pour communiquer avec SharePoint.
Le même mécanisme s’applique aux personnalisations créées sur SharePoint Framework, qui s’exécutent également sous le contexte de l’utilisateur actuellement authentifié et qui ne nécessitent pas d’étapes d’authentification supplémentaires afin de communiquer avec SharePoint. Le contexte de sécurité est celui de l’utilisateur actuellement connecté, ce qui implique que, du point de vue de la sécurité, vous devez être prudent lors de l’installation d’une extension SharePoint Framework dans n’importe quelle collection de sites cible.
Utilisation du code côté client uniquement
Les extensions de SharePoint Framework, les actions personnalisées de l’utilisateur et les éléments de menu BCE s’exécutent tous dans le navigateur et peuvent contenir uniquement du code JavaScript côté client. Les solutions côté client rencontrent plusieurs limitations. Par exemple, elles ne peuvent pas élever les autorisations dans SharePoint ou communiquer avec des API externes qui ne prennent pas en charge la communication CORS ou l’authentification à l’aide du flux implicite OAuth. Dans ce cas, la solution côté client peut tirer parti d’une API côté serveur distante pour effectuer l’opération nécessaire et retourner les résultats au client.
Modèle d’hébergement auto-cohérent et basé sur Microsoft 365
Les extensions SharePoint Framework et les solutions d’action personnalisée utilisateur ou d’élément de menu BCE peuvent être hébergées sur SharePoint Online, et éventuellement dans le service CDN Microsoft 365, ce qui évite d’avoir besoin de services externes ou d’environnements d’hébergement.
Bien que l’hébergement de solutions SharePoint Framework sur un CDN offre de nombreux avantages, il n’est pas obligatoire et vous pouvez choisir d’héberger le code dans une bibliothèque de documents SharePoint. SharePoint Framework packages (fichiers *.sppkg) déployés dans le catalogue d’applications spécifient l’URL à laquelle SharePoint Framework pouvez trouver le code de la solution. Si l’utilisateur qui parcourt la page comportant l’extension peut télécharger le script à partir de l’emplacement spécifié, il n’existe aucune restriction concernant la nature de l’URL.
Microsoft 365 offre la fonctionnalité CDN publique qui vous permet de publier des fichiers d’une bibliothèque de documents SharePoint spécifique dans un CDN. Le CDN public Microsoft 365 offre un bon équilibre entre les avantages de l’utilisation d’un CDN et la simplicité d’hébergement des fichiers de code dans une bibliothèque de documents SharePoint. Si votre organisation ne veut pas que ses fichiers de code soient disponibles publiquement, l’utilisation du CDN public Microsoft 365 est une option à prendre en compte.
Différences entre les solutions SharePoint Framework et les personnalisations SharePoint Feature Framework
Toutefois, ces deux modèles de développement présentent aussi des différences notables, dont vous devez tenir compte quand vous concevez l’architecture de vos solutions.
Exécution dans des sites sans script
Étant donné que SharePoint Framework solutions, y compris les extensions, sont déployées via le catalogue d’applications avec une approbation préalable, elles ne sont pas soumises aux restrictions sans script et fonctionnent sur tous les sites « modernes ».
Ensemble prédéfini de points d’extensibilité
Alors qu’une action personnalisée utilisateur peut incorporer du code JavaScript qui peut mettre à jour ou modifier le DOM de n’importe quelle partie de la page, une extension SharePoint Framework peut uniquement personnaliser les zones prises en charge de pages « modernes ».
En théorie, vous pouvez créer un personnalisateur d’application qui peut complètement modifier la structure d’une page à l’aide d’un DOM, comme vous pouvez le faire avec les actions personnalisées de l’utilisateur. SharePoint Framework mise sur l’utilisation d’une approche plus structurée et plus fiable pour personnaliser SharePoint. Au lieu d’utiliser des éléments DOM spécifiques pour personnaliser SharePoint, SharePoint Framework fournit aux développeurs des hooks et des espaces réservés spécifiques, que nous vous recommandons d’utiliser.
Utilisation de TypeScript pour créer des solutions plus robustes et plus faciles à tenir à jour
Lors de la création de personnalisations à l’aide des actions personnalisées de l’utilisateur ou des éléments de menu ECB, les développeurs utilisaient souvent JavaScript. Souvent, ces solutions ne comportaient aucun test automatisé et la refactorisation du code pouvait engendrer des erreurs.
SharePoint Framework permet aux développeurs de profiter du système de type TypeScript lors de la création de solutions. Grâce au système de type, de nombreuses erreurs sont interceptées pendant le développement plutôt qu’au moment de l’exécution. De plus, le processus de refactorisation du code est désormais plus simple, car les modifications apportées au code sont protégées par TypeScript. Comme l’ensemble du langage JavaScript constitue un langage TypeScript valide, la barrière à l’entrée est faible et vous pouvez migrer petit à petit votre langage JavaScript vers TypeScript, en augmentant la maintenabilité de vos solutions.
Aucun accès par défaut au modèle objet JavaScript SharePoint
Lorsqu’ils créaient des personnalisations côté client pour l’expérience utilisateur SharePoint classique, de nombreux développeurs utilisaient le modèle objet JavaScript (JSOM) pour communiquer avec SharePoint. Grâce à JSOM, ils disposaient d’IntelliSense et d’un accès facile à l’API SharePoint de façon semblable au modèle objet côté client (CSOM). Dans les pages SharePoint classiques, la partie principale du JSOM était présente par défaut sur la page, et les développeurs pouvaient charger d’autres parties pour communiquer avec la recherche SharePoint, par exemple.
L’expérience utilisateur SharePoint moderne n’inclut pas le JSOM SharePoint par défaut. Alors que les développeurs peuvent le charger eux-mêmes, nous vous recommandons plutôt d’utiliser l’API REST, ou la bibliothèque principale JavaScript des modèles et pratiques SharePoint (bibliothèque PnP JS), qui utilise en interne l’API REST SharePoint. L’utilisation de REST a un caractère plus universel et interchangeable entre les différentes bibliothèques côté client, telles que jQuery, Angular ou React.
Microsoft ne va plus travailler activement sur le JSOM. Si vous préférez utiliser une API, vous pouvez utiliser la bibliothèque JS PnP, qui vous offre une API Fluent et des frappes TypeScript.
Migration de personnalisations existantes vers les extensions de SharePoint Framework
La migration de personnalisations existantes vers les extensions de SharePoint Framework présente de nombreux avantages pour les utilisateurs finals et les développeurs. Lorsque vous envisagez de migrer des personnalisations existantes vers le SharePoint Framework, vous pouvez choisir de réutiliser autant de scripts JavaScript existants que possible, ou de réécrire complètement la personnalisation à l’aide de TypeScript.
Réutilisation de scripts existants
Quand vous migrez des personnalisations existantes vers les extensions de SharePoint Framework, vous pouvez choisir de réutiliser vos scripts existants. Bien que SharePoint Framework encourage l’utilisation de TypeScript, vous pouvez utiliser le langage JavaScript brut et le transformer petit à petit en langage TypeScript. Cette approche peut vous convenir si vous devez prendre en charge une solution pendant une durée limitée ou si vous disposez d’un budget limité.
Il n’est pas toujours possible de réutiliser des scripts existants dans une solution SharePoint Framework. Par exemple, étant donné la variété des bibliothèques JavaScript, il n’existe aucun moyen simple de déterminer si vos scripts existants peuvent être réutilisés dans une solution SharePoint Framework ou si vous devez les réécrire. La seule façon de le savoir consiste à essayer de déplacer les différentes parties vers une solution SharePoint Framework et de voir si elles fonctionnent comme prévu.
Réécriture de la personnalisation
Si vous avez besoin de prendre en charge votre solution pendant une période plus longue ou si vous souhaitez mieux utiliser les SharePoint Framework, ou s’il s’avère que vos scripts existants ne peuvent pas être réutilisés avec le SharePoint Framework, vous devrez peut-être réécrire complètement votre personnalisation. Bien qu’elle soit plus coûteuse que la réutilisation des scripts existants, elle vous offre de meilleurs résultats sur une période plus longue : une solution plus performante et plus facile à gérer.
Lors de la réécriture d’une personnalisation existante dans une solution SharePoint Framework, vous devez commencer par la fonctionnalité souhaitée à l’esprit. Pour implémenter l’expérience utilisateur, vous devez envisager d’utiliser Office UI Fabric afin que votre solution semble faire partie intégrante de SharePoint.