Migration de personnalisations JSLink vers des personnalisateurs de champ SharePoint Framework
Le SharePoint Framework (SPFx) est le modèle recommandé pour l’extension et la création de personnalisations SharePoint. Si vous avez personnalisé des champs SharePoint et des affichages de liste avec JSLink, vous vous demandez peut-être quel est l’avantage de migrer ces personnalisations vers SPFx.
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 personnalisateurs de champs soient le chemin de migration naturel de JSLink, vous devez également évaluer à l’aide de la mise en forme de liste et de colonne pour personnaliser l’affichage 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.
Vous pouvez en savoir plus ici : Utiliser la mise en forme de colonne pour personnaliser SharePoint
Avantages de la migration de personnalisations JSLink existantes vers SharePoint Framework
Le SharePoint Framework a été conçu pour étendre l’expérience « moderne » de SharePoint. 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 toute 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 s’appuyer sur les personnalisations JSLink héritées. Si vous souhaitez vraiment étendre l’interface utilisateur « moderne », vous devez migrer la solution JSLink vers un personnalisateur de champ SharePoint Framework.
Accès plus facile aux informations dans SharePoint et Microsoft 365
Un autre sujet fondamental à prendre en compte est que dans les personnalisations JSLink héritées, il n’était pas facile de consommer du contenu et des données SharePoint. La seule façon de procéder était d’utiliser le modèle objet côté client (JSOM) JavaScript ou des API REST de bas niveau. Il était presque impossible de consommer l’ensemble complet des services de Microsoft 365, sauf si vous avez utilisé 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 personnalisations JSLink et SharePoint Feature Framework partagent des similitudes.
Modèle de mise en service
Les extensions SharePoint Framework et les actions personnalisées utilisateur ou les solutions d’éléments de menu ECB utilisent un fichier manifeste XML, qui est é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
À l’instar des actions personnalisées de l’utilisateur et d’ECB 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é que SharePoint Framework extensions s’exécutent dans le cadre de la page, quelles que soient les ressources auxquelles la personnalisation a accès, d’autres éléments de la page peuvent également 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é que SharePoint Framework extensions s’exécutent dans le cadre de la page, d’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. Lors de la création d’extensions SharePoint Framework, vous pouvez utiliser n’importe quelle bibliothèque côté client pour enrichir votre solution, comme vous l’aviez fait par 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 extensions SharePoint Framework et les personnalisations JSLink s’exécutent 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 fichiers JavaScript pour les personnalisations JSLink peuvent être hébergés 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 JSLink
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 personnalisateurs de champs de SharePoint Framework fonctionnent dans des listes et des bibliothèques « modernes », contrairement à L’ancienne bibliothèque JSLink.
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 la rédaction de cet article, un personnalisateur de champ de SharePoint Framework peut personnaliser le rendu d’un champ uniquement en mode de rendu d’affichage liste, tandis que dans l’affichage et la modification des affichages d’un seul élément, 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 ont utilisé le modèle JSOM pour communiquer avec SharePoint. Le modèle JSOM leur offrait 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 modèle JSOM était présent par défaut sur la page, et les développeurs pouvaient charger des éléments supplémentaires pour communiquer avec la recherche SharePoint, par exemple.
L’expérience utilisateur SharePoint moderne n’inclut pas le JSOM SharePoint par défaut. Bien que les développeurs puissent le charger eux-mêmes, il est recommandé d’utiliser l’API REST à la place, ou la bibliothèque JavaScript Core (PnPJS) SharePoint Patterns and Practices, 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’investit pas activement dans le modè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
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 de 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 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 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 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.