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 SharePoint personnalisations. Si vous avez personnalisé des SharePoint avec des actions personnalisées de l’utilisateur et des éléments de menu BCE (Bloc de contrôle d’édition) 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 sont un remplacement approprié pour les éléments de menu ECB. Enfin, les personnaliseurs 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 personnaliser des sites « modernes » sans script

L’un des principaux avantages de la migration des personnalisations SharePoint Feature Framework héritées vers le SharePoint Framework est qu’il s’agit de la seule technique prise en charge sur les sites modernes pour la personnalisation de l’interface utilisateur.

En fait, l’indicateur Aucun script est activé sur les sites « modernes », ce qui évite d’exécuter des scripts incorporés dans la page, ainsi que toute action personnalisée par l’utilisateur, qui fait référence à javaScript externe ou à JavaScript incorporé.

Les actions personnalisées de l’utilisateur hérité ne fonctionnent simplement pas dans l’interface utilisateur « moderne ». Les personnalisations ECB conçues à l’aide de Feature Framework sont limitées. Vous pouvez uniquement définir des éléments ECB 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 mettre à 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 par l’utilisateur et de personnalisations ECB, il n’était pas facile d’utiliser du contenu SharePoint données. 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 d’utiliser l’ensemble complet des services de Microsoft 365, à moins que vous n’tirez parti de manière autonome de ADAL.JS (bibliothèque d’authentification Azure Active Directory pour JavaScript) et du code JavaScript personnalisé.

Désormais, avec les extensions SharePoint Framework et SharePoint Framework, il est facile et simple de consommer à la fois 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 de services fournis par Microsoft 365.

Similarités entre les solutions SharePoint Framework et les personnalisations SharePoint Feature Framework

Les actions personnalisées de SharePoint Feature Framework et les éléments ECB et les personnalisations SharePoint Feature Framework partagent des similitudes.

Modèle de mise en service

Les extensions SharePoint Framework les actions personnalisées de l’utilisateur ou les solutions d’élément de menu ECB exploitent un fichier manifeste XML é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

Lors de la création de personnalisations de page à l’aide d’actions personnalisées par l’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 le SharePoint Framework offre est l’isolation de votre script. Même si le partie Web Part est exécutée en tant que partie 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 uns 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 faire l’opération nécessaire et renvoyer les résultats au client.

Modèle d’hébergement autonome et basé sur Microsoft 365

Les extensions SharePoint Framework et l’action personnalisée de l’utilisateur ou les solutions d’élément de menu BCE peuvent être hébergées sur SharePoint Online, puis dans le service Microsoft 365 CDN, ce qui évite tout 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, cela n’est pas obligatoire et vous pouvez choisir d’héberger le code dans une bibliothèque SharePoint documents. Les packages SharePoint Framework (fichiers *.sppkg) déployés vers le catalogue d’applications indiquent l’URL avec laquelle SharePoint Framework peut 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é de CDN public qui vous permet de publier des fichiers à partir d’une bibliothèque SharePoint de documents spécifique vers une CDN. Microsoft 365 public CDN équilibre entre les avantages de l’utilisation d’un CDN et la simplicité d’hébergement de fichiers de code dans une bibliothèque de documents SharePoint. Si votre organisation ne se fiche pas que ses fichiers de code sont disponibles publiquement, l’utilisation de la Microsoft 365 public CDN est une option intéressante à envisager.

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 les solutions SharePoint Framework, 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é

Bien qu’une action personnalisée par l’utilisateur puisse incorporer du code JavaScript qui peut mettre à jour ou modifier le DOM de n’importe quelle partie de la page, une extension SharePoint Framework ne peut personnaliser que les zones prises en charge des 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 capturées lors du développement plutôt que lors de l’runtime. 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 typages 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 plus longtemps, si vous souhaitez mieux utiliser le 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’il soit plus coûteux que de réutiliser des scripts existants, il offre de meilleurs résultats sur une plus longue période : une solution qui est plus efficace et plus facile à gérer.

Lors de la réécriture d’une personnalisation existante vers une solution SharePoint Framework, vous devez commencer avec les fonctionnalités recherchées à 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.

Voir aussi