Migration de personnalisations JSLink vers des personnalisateurs de champ SharePoint Framework

Le SharePoint Framework (SPFx) est le modèle recommandé pour étendre et créer des SharePoint personnalisées. Si vous avez personnalisé SharePoint des champs et des affichages de liste avec JSLink, vous vous demandez peut-être quel est l’avantage de migrer ces personnalisations vers SPFx est.

Tout d’abord, voici les options disponibles lors du développement des extensions de SharePoint Framework :

  • 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 vos personnalisations, vous pouvez tirer parti des avantages offerts par les versions ci-dessus. Par exemple, les personnalisateurs de champ peuvent remplacer les personnalisations de champ JSLink.

Conseil

Bien que les personnaliseurs de champ soient le chemin de migration naturelle de JSLink, vous devez également évaluer à l’aide de la mise en forme de liste et de colonne pour personnaliser l’affichage de liste. Les deux technologies ont leurs avantages et inconvénients individuels, et l’une peut être plus simple à implémenter et à gérer que l’autre en fonction de votre scénario.

Pour plus d’informations, voir : Utiliser la mise en forme des colonnes pour personnaliser SharePoint

Le SharePoint Framework a été conçu pour étendre SharePoint expérience « moderne ». L’expérience « moderne » est disponible sur les sites d’équipe « modernes » et les sites de communication « modernes », et qui cible n’importe quel appareil et n’importe quelle plateforme.

Une seule méthode de personnalisation des bibliothèques et des listes « modernes »

L’un des principaux avantages de la migration des personnalisations JSLink héritées vers le SharePoint Framework est qu’il s’agit de la seule option prise en charge disponible. En fait, les listes et bibliothèques « modernes », en raison de leur infrastructure de rendu et de l’indicateur sans script activé sur les sites « modernes », ne peuvent pas compter sur les personnalisations JSLink héritées. Si vous souhaitez vraiment étendre l’interface utilisateur « moderne », vous devez migrer la solution JSLink vers un personnal SharePoint Framework de champ.

Accès plus facile aux informations dans SharePoint et Microsoft 365

Une autre rubrique fondamentale à prendre en considération est que dans les personnalisations JSLink héritées, il n’était pas facile d’SharePoint contenu et de données. La seule façon de le faire était d’utiliser le modèle objet côté client JavaScript (JSOM) ou les API REST de bas niveau. Il était presque impossible d’utiliser l’ensemble complet des services de Microsoft 365 sauf si vous avez utilisé ADAL.JS (Azure Active Directory Authentication Library pour JavaScript) et du code JavaScript personnalisé.

Désormais, avec les extensions SharePoint Framework et 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 de services fournis par Microsoft 365.

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

Les personnalisations JSLink 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 utilisent un fichier manifeste XML écrit avec la syntaxe SharePoint Feature Framework. Ainsi, le déploiement repose sur les mêmes techniques. Cependant, avec les nouveaux personnalisateurs de champ, vous pouvez personnaliser le rendu d’un champ, et non le rendu de l’affichage seul d’une liste ou d’une bibliothèque. Le champ personnalisé peut être utilisé dans autant de listes et de bibliothèques que vous le souhaitez.

Exécution en tant qu’une partie de la page

Tout comme les actions personnalisées par l’utilisateur et la bce de SharePoint Feature Framework, les extensions 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é SharePoint Framework extensions s’exécutent dans le cadre de la page, quelles que soient les ressources à qui la personnalisation a accès, les autres éléments de la page peuvent également y accéder. 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é SharePoint Framework extensions s’exécutent en tant que partie de la page, les autres éléments de cette page peuvent également accéder à toutes ces ressources.

Création des extensions à l’aide de la bibliothèque de votre choix

Quand vous créez des personnalisations de page à l’aide des actions personnalisées de l’utilisateur, vous pouvez utiliser des bibliothèques, telles que jQuery ou Knockout, pour rendre votre personnalisation dynamique et plus réactive aux actions des utilisateurs. Lorsque vous SharePoint Framework des extensions, vous pouvez utiliser n’importe quelle bibliothèque côté client pour enrichir votre solution, comme vous l’ariez fait dans le passé.

Un autre des avantages offerts par SharePoint Framework est la possibilité d’isoler votre script. Même si le composant WebPart est exécuté comme une partie de la page, son script se présente sous forme de module ce qui permet, par exemple, à différentes extensions de la même page d’utiliser une version distincte de jQuery sans entrer en conflit. 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 de JSLink, 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 SharePoint Framework et les personnalisations JSLink s’exécutent dans le navigateur et ne peuvent contenir que 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 les fichiers JavaScript pour les personnalisations JSLink peuvent être hébergés sur SharePoint Online, puis dans le service Microsoft 365 CDN, évitant ainsi les services externes ou les 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. SharePoint Framework packages ( fichiers * .sppkg) déployés dans le catalogue d’applications spécifient l’URL à laquelle SharePoint Framework 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.

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, ainsi que des bibliothèques et des listes « modernes »

É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 ». Comme nous l’avons déjà vu, les personnaliseurs de champ de SharePoint Framework fonctionnent dans des listes et des bibliothèques « modernes », alors que le JSLink hérité ne fonctionne pas.

Prise en charge de l’affichage seul par les personnalisateurs de champ

Une personnalisation JSLink peut servir à personnaliser l’affichage d’un champ dans une liste ou une bibliothèque, mais aussi le mode d’édition et d’affichage d’un champ quand vous affichez un seul élément.

Au moment de cette écriture, un personnaliste de champ de SharePoint Framework peut personnaliser le rendu d’un champ uniquement dans le mode de rendu d’affichage de liste, tandis que dans les affichages d’affichage et de modification d’un élément unique, vous ne pouvez pas tirer parti de la personnalisation.

Utilisation de TypeScript pour créer des solutions plus robustes et plus faciles à tenir à jour

Quand ils créaient des personnalisations à l’aide de JSLink, les développeurs utilisaient souvent le langage JavaScript brut. 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, les erreurs sont détectées pendant le développement, et non pendant 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

Lors de la création de personnalisations côté client pour l’expérience utilisateur SharePoint classique, de nombreux développeurs utilisaient le JSOM pour communiquer avec SharePoint. Le JSOM leur IntelliSense et un accès facile à l’API SharePoint d’une manière similaire au modèle objet Client-Side (CSOM). Dans les pages SharePoint classiques, l’élément principal du JSOM était présent par défaut sur la page, et les développeurs pouvaient charger des éléments supplémentaires pour communiquer avec SharePoint Search, par exemple.

L’expérience utilisateur SharePoint moderne n’inclut pas le JSOM SharePoint par défaut. Bien que les développeurs peuvent le charger eux-mêmes, il est recommandé d’utiliser l’API REST à la place ou la bibliothèque principale JavaScript (PnPJS) des modèles et pratiques SharePoint, 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 n’investira pas activement dans 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 déclarations de type TypeScript.

Migrer la personnalisation existante vers les extensions SharePoint Framework de migration

La migration des personnalisations existantes vers les extensions SharePoint Framework offre de nombreux avantages aux utilisateurs finaux et aux 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

Lors de la migration des personnalisations existantes vers les extensions 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. Étant donné la variété des bibliothèques JavaScript, il n’existe aucun moyen simple de savoir à l’avance si vos scripts existants peuvent être réutilisés dans une solution SharePoint Framework ou si vous devrez 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 que cette solution soit plus onéreuse que de réutiliser les scripts existants, elle donne de meilleurs résultats dans le temps : une solution qui fonctionne mieux, qui est plus facile à tenir à jour et à utiliser.

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