Onboarding SPFx


SPFx, oui déjà entendu parlé !!!

 

Mais je suis toujours la tête dans le guidon et n’est, hélas, pu commencer le fameux HelloWorld project !

Très bien, cet article est fait pour toi !

Je ne vais pas t’expliquer comment faire le WebPart HelloWorld puisque le tuto est disponible ici https://dev.office.com/sharepoint/docs/spfx/web-parts/get-started/build-a-hello-world-web-part

Non, je te propose de prendre un peu de recul et de comprendre comment fonctionne ce nouveau framework qui exploite des outils que tu n’as peut être jamais utilisé jusqu’ici en tant que SPFarmer.

YEOMAN, ça te parle ?

yoman_400x400

C’est une suite de 3 outils :

yo

YO, se charge de construire l’arborescence du projet à partir d’un modèle,

 

npm

NPM, permet de gérer les packages et leur dépendance,

 

 

gulp

GULP, est un outil de compilation.

 

Et comment tout cela fonctionne ?

spfx-schema

 

    1. Tout d’abord, il est nécessaire d’instancier un nouveau projet avec YO du type SharePoint,
    2. Le type ou modèle de projet est référencé sur NPM et redescendu sur votre machine,
    3. Il faut ensuite développer son application à partir du template qui exploite : TypeScript, REST, SCSS, REACT ou Knockout.JS (pour l’instant) : c’est donc du full client-side. J’espère avoir l’occasion de rentrer dans le détail du développement à proprement dit dans un prochain article rapidement.
    4. Lorsque l’on souhaite compiler son WebPart, il suffit de lancer la commande GULP SERVE.

gulpserve

  1. a : Les fichiers sont compilés TS vers JS, SCSS vers CSS, etc…
  1. b : un serveur web est monté avec NODE.JS

 

Chose importante, la commande GULP SERVE ne rend pas la main dans l’invite de commande et reste donc active.

A chaque changement de fichier source (TS, SCSS ou autre), GULP va automatiquement recompiler.

Ce n’est donc plus le moteur de visual studio qui fait le boulot et étant donné que tout tourne côté client le rechargement prend seulement quelques secondes.

Oui, vous pouvez tester en quelques secondes votre code J.

Terminé le process long et fastidieux de la compilation puis création du package, retrait du package sur le tenant et installation du package qui prend plus d’1 minute.

Et ça, j’achète !

 

La solution la plus simple pour tester le webpart est d’exploiter la page web de test générée localement, point 6a sur le schéma.

  1. a : La commande GULP SERVE lance automatiquement votre navigateur sur la page workbench.htmlCette page reprend le style graphique des Modern Pages SharePoint Online.Il suffit de lancer l’ajout du composant webpart du projet.

local-workbench

 

Attention cette technique ne permet pas d’intéragir avec l’environnement SharePoint Online.

Il vous faudra donc créé des données fictives qui seront chargées dans ce contexte local.

Le tuto parle de « Mock store » : https://dev.office.com/sharepoint/docs/spfx/web-parts/get-started/connect-to-sharepoint

La détection du mode local ou SharePoint est possible grâce à la propriété Environment.type

 

  1. b : l’autre solution consiste donc à tester directement sur SharePoint Online au travers de la page applicative /_layouts/workbench.aspx
  2. b’ : pour rappel, la techno est client-side full, donc finalement votre navigateur ouvre un WebPart qui exécute du code directement dans le naviguateur. Il ne se passe rien côté serveur hormis les traitements REST.

Les fichiers CSS, JS sont directement chargés sur votre serveur web local monté à l’aide de la commande GULP.

 

Ce processus est donc viable en phase de développement, en cas de déploiement réel sur SharePoint Online via un package, il convient de faire héberger les fichiers sur un CDN.

Ca tombe bien, SPFx propose d’exploiter Azure par défaut 😉

 

La suite au prochain épisode …

 

Laisser un commentaire