Partager via

Pourquoi SharePoint Framework ?

SharePoint a été initialement lancé en tant que produit local en 2001. Au fil du temps, une importante communauté de développeurs l’a agrandi et façonné de plusieurs façons. La communauté de développeurs a suivi les mêmes modèles et les mêmes pratiques que l’équipe de développement SharePoint, notamment des composants, des fichiers de fonctionnalités SharePoint XML, et bien plus encore. De nombreuses fonctionnalités ont été écrites en tant que personnalisations côté serveur à l’aide de C#, compilées en DLL et déployées sur des batteries de serveurs locales.

Ce système fonctionnait bien dans les environnements ne comprenant qu’une entreprise, mais il n’était pas extensible dans le cloud, où plusieurs clients fonctionnent côte-à-côte sur les mêmes serveurs. Par conséquent, nous avons introduit deux modèles de remplacement : l’injection JavaScript côté client et les compléments SharePoint. Ces deux solutions ont des avantages et des inconvénients.

Injection JavaScript

L’un des composants les plus populaires de SharePoint Online est l’Éditeur de Script. Vous pouvez ajouter du JavaScript au composant WebPart Éditeur de script et faire en sorte que JavaScript s'exécute lors du rendu de la page. C’est simple & efficace. Le code s’exécute dans le même contexte de navigateur que la page et se trouve dans le même DOM, ce qui lui permet d’interagir avec d’autres contrôles sur la page. C’est également relativement performant et facile à utiliser.

Cette approche comporte cependant quelques inconvénients :

  • Tout d’abord, bien que vous puissiez mettre votre solution en package pour que les utilisateurs finals puissent déposer le contrôle sur la page, il n’existe pas de moyen simple de fournir des options de configuration.
  • L'utilisateur final peut éditer la page et modifier le script, ce qui peut casser le composant WebPart.
  • Le site Web Part Éditeur de Scripts n’est pas marqué comme Sûr pour l'écriture de scripts. Sur la plupart des collections de sites en libre-service (Mes sites, sites d’équipe, sites de groupe), une fonctionnalité appelée « NoScript » est activée. Techniquement, il s’agit de la suppression de l’autorisation Ajouter/Personnaliser des pages dans SharePoint. Cela signifie que l’exécution du composant WebPart Éditeur de script est bloquée sur ces sites.

Modèle de complément SharePoint

Une option pour les solutions qui s'exécutent dans les sites NoScript est le modèle de complément/partie d'application introduit dans SharePoint Server 2013. Cette implémentation crée un iFrame qui abrite et exécute l’expérience elle-même. L’avantage est que, étant donné qu’elle externe au système et n’a pas accès à la connexion/au DOM actuel, elle est plus fiable et plus facile à déployer pour les informaticiens. Les utilisateurs finaux peuvent installer des compléments sur les sites NoScript.

Cette approche comporte cependant des inconvénients

  • Ils s’exécutent dans un iFrame. Les iFrames sont plus lents que le composant WebPart Éditeur de script, car ils requièrent une nouvelle demande vers une autre page. Cette page doit passer par le processus d’authentification et d’autorisation, effectuer ses propres appels pour obtenir les données de SharePoint, charger différentes bibliothèques JavaScript, et plus encore. Un composant WebPart Éditeur de script mettra généralement autour de 100 millisecondes pour charger et rendre le contenu, tandis qu’un composant d’application peut mettre 2 secondes ou plus.
  • La limite iFrame rend plus difficile la création de conceptions réactives et l'héritage des informations CSS et thématiques. Les iFrames ont une sécurité renforcée, ce qui peut être utile pour vous (votre page est inaccessible par d'autres contrôles de la page) et pour l'utilisateur final (le contrôle n'a pas accès à sa connexion à Microsoft 365).

SharePoint Framework

Historiquement, les développeurs créaient des composants WebPart en tant qu'assemblys C# de confiance totale qui étaient installés sur les serveurs cloud.

Toutefois, les modèles de développement actuels impliquent généralement l’exécution de JavaScript dans un navigateur effectuant des appels d’API REST aux charges de travail back-end SharePoint et Microsoft 365. Les assemblys C# ne fonctionnent pas dans ce système. Les développeurs avaient besoin d’un nouveau modèle de développement.

SharePoint Framework constitue la nouvelle phase d’évolution pour le développement SharePoint.

Voir aussi