Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Découverte des concepts architecturaux

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • Expliquer la différence entre le paradigme des pages Visualforce et celui des composants Aura
  • Expliquer le concept de différents conteneurs et la manière d’insérer une application ou un composant Aura dans un conteneur

Concept : Application page-à-page ou à page unique

Lorsque vous concevez une application Visualforce traditionnelle, vous créez généralement une série de pages, et les utilisateurs de l’application naviguent en se déplaçant d’une page à l’autre. Vous commencez par une page de vue de liste, vous cliquez sur un lien afficher pour aller sur la page d’affichage d’un enregistrement, puis vous cliquez sur un bouton modifier pour aller sur la page de modification d’un enregistrement, etc.

Les applications de composants Aura sont très différentes. Il n’y a qu’une seule « page » pour toute l’application ! On les appelle applications monopages (SPA). Les SPA chargent une seule page et beaucoup de JavaScript. Après le chargement, le JavaScript est exécuté et met à jour l’interface utilisateur de la « page ».

Au lieu de naviguer de page en page, l’utilisateur va d’état en état. Un état représente le mode dans lequel votre application se trouve actuellement. L’état de vue de liste, l’état d’affichage d’un enregistrement, etc.

La SPA sait quels composants charger pour chaque état, et ces composants savent de quelle manière ils doivent s’afficher.

Deux choses à retenir pour vous. D’une part, la navigation est très différente dans les composants Aura. Selon la complexité de votre application et l’endroit où elle sera exécutée, il se peut que vous n’ayez jamais à vous poser la question de la navigation. Dites adieu à PageReference, à $Action, et au contre-modèle que représentent les URL construites à la main. (L’horreur !)

Cependant, il est probable que vous deviez apprendre de nouvelles astuces. Consultez les ressources pour savoir par où commencer.

D’autre part… voilà matière pour un nouveau concept.

Concept : Page ou composant

Nous avons déjà parlé de la manière dont les pages Visualforce et les composants Aura sont stockés dans Salesforce. Il y a quelques petites différences, mais à ce niveau ils sont très similaires. Ce sont des bouts de code, et cette page ou ce composant est la brique de base avec laquelle vous travaillez.

Mais ce qui change beaucoup, c’est la manière de construire une application avec ces deux types de briques.

Remarque

Remarque

Pour l’instant, ignorons les composants Visualforce. Nous les aborderons dans la section suivante.

Pour simplifier, une page Visualforce est une « grosse » brique. Même si vous pouvez l’intégrer à la présentation d’une page sous forme de widget ou intégrer une page à une autre avec la balise <apex:include>, vous ne le ferez que pour quelques pages. Vous ne créez pas un ensemble de « petites » pages pour bâtir une page « moyenne », avant de les rassembler pour faire une « grosse » page. Visualforce n’est pas conçu dans ce sens, et si vous essayez quand même, vous rencontrerez des problèmes.

Le composant Aura est différent. Un « gros » composant Aura peut être composé de dizaines, voire de centaines de petits composants, qui eux-mêmes peuvent être composés de nombreux composants encore plus petits. Le modèle de programmation Aura est conçu pour gérer des milliers de composants rassemblés dans une seule application.

Lors de l’utilisation de composants Aura, la procédure de conception fondamentale consiste à prendre les petits composants spécialisés et à les assembler dans un composant de niveau supérieur, de façon répétitive. En conception logicielle, on appelle cette technique la composition, ce qui retranscrit bien la proximité avec le terme « composant » (la racine latine com signifie ensemble, avec). Ce n’est pas un hasard.

Une page Visualforce est globalement prévue pour fonctionner en autonomie. C’est l’une des raisons pour lesquelles elle est accessible depuis une URL unique et stable.

Cependant, un composant Aura doit faire partie d’un ensemble plus vaste, peu importe la taille du composant. Il n’y a pas d’URL qui permet d’accéder à chaque composant individuel. Pour exécuter un composant, vous devez l’intégrer à un ensemble plus vaste, comme nous l’avons fait dans le module Compétences et outils pour composants Aura.

Il y aurait encore beaucoup à dire à ce sujet : il y a des livres entiers sur l’utilisation de composants pour concevoir des logiciels. Pour l’instant, souvenez-vous juste de ne pas traiter un composant comme une page !

Concept : Composant ou composant

Dans les sections précédentes, nous avons ignoré les composants Visualforce. C’est injuste. Après tout, beaucoup des « balises » intégrées au framework Visualforce sont seulement des composants, mais avec un autre nom. Bien sûr, Visualforce a des composants ; les pages Visualforce peuvent utiliser des centaines de « balises » intégrées, ce qui les rend assez semblables aux composants Aura. Quelle est la différence ?

En quelques mots, lorsque Salesforce conçoit un nouveau composant (ou balise) Visualforce, nous avons accès à plus de fonctionnalités que quand vous développez des composants Visualforce personnalisés. Nous avons remis un certain nombre de ces fonctionnalités dans la partie orientée client des composants Aura. Les composants Visualforce personnalisés sont moins puissants et moins fonctionnels que les composants Aura personnalisés.

Une précision importante ! Beaucoup de nos clients créent des composants Visualforce personnalisés efficacement. Les composants Visualforce personnalisés sont très bien. Il n’y a aucun mal à les utiliser ! Ils sont le signe d’un travail de développement pointu, et ils permettent généralement de réduire les coûts de déploiement logiciel à long terme. Nous ne sommes pas en train de dire que les composants Visualforce personnalisés ne sont pas bons.

Les composants Aura sont simplement meilleurs. Ils sont plus sophistiqués et plus puissants. Si vous prenez le temps d’apprendre à les utiliser correctement, vous pourrez créer des logiciels plus riches pour un coût comparable.

Penchons-nous sur les principales différences.

  • Les composants Aura peuvent déclencher et recevoir des événements afin de communiquer entre composants. Vous pouvez travailler avec des événements du framework ou du conteneur, ou définir les vôtres. Vous écrivez des gestionnaires d’événements, et le framework s’occupe du détail de leur invocation lorsque le bon événement se produit. C’est incroyable ! Les composants Aura ouvrent aux concepteurs d’applications de nouveaux horizons. Il n’y a rien de comparable dans Visualforce, sauf si vous le créez vous-même. Si c’est le cas, bravo, vous avez inventé votre propre framework ! Il ne vous reste plus qu’à trouver un nom ironique, un dépôt GitHub et des lunettes de hipster.
  • La structure en paquets des composants Aura dispose d’artefacts distincts pour des fonctions distinctes et les connecte automatiquement. Pouvoir regrouper les dépendances essentielles d’un composant tout en gardant les différents éléments séparés est un excellent outil d’organisation. Les fournisseurs de valeurs, entre autres, permettent d’utiliser facilement les différents éléments, avec un minimum d’efforts. Encore une fois, pour obtenir quelque chose de comparable dans Visualforce, le code qu’il vous faudrait écrire devrait être celui d’un framework et non de fonctionnalités.
  • Les composants Aura peuvent être utilisés dans davantage de contextes. Comme il s’agit de code côté client, vous pouvez utiliser Lightning Out pour transférer vos fonctionnalités « Salesforce » vers d’autres applications autres que Salesforce, par exemple SharePoint. Visualforce dépend du serveur et ne fonctionne que sur Salesforce.

Nous pourrions continuer longtemps, mais il vaut mieux passer à de nouveaux concepts. Avec un peu de chance, d’ici la fin de ce module, vous aurez une idée précise des raisons qui pourraient vous pousser à envisager sérieusement les composants Aura.

Concept : Conteneurs d’application

Les conteneurs d’application (qu’on appellera simplement des conteneurs) sont un nouveau concept pour la plupart des développeurs Salesforce. En termes simples, un conteneur est un contexte d’application ou un environnement dans lequel votre code est exécuté. Lightning Experience est indéniablement le conteneur le plus approprié pour les composants Aura. Comme Lightning Experience et l’application Salesforce ont beaucoup de code en commun, accessible depuis les mêmes URL, nous appellerons parfois la combinaison des deux « le conteneur one.app ». (L’URL commune aux deux se termine par one.app.)

Remarque

Remarque

Il existe des différences importantes entre Lightning Experience et l'application Salesforce, car on accède plus souvent à l’application Salesforce par une application native depuis un appareil mobile, plutôt que par un navigateur Web. Nous n’aborderons pas la question ici, mais soyez vigilant.

Vous avez peut-être deviné que Salesforce Classic est un autre conteneur. Voici une liste (non exhaustive) de conteneurs dans lesquels votre code pourra être exécuté :

  • Salesforce Classic
  • Visualforce
  • Application Salesforce
  • Lightning Experience
  • Générateur d'applications Lightning (LAB)
  • Applications Lightning Console
  • Communautés
  • Composants Lightning pour Visualforce (LC4VF)
  • Lightning Out
  • Lightning pour Outlook et Lightning pour Gmail
  • my.app autonome

Après avoir lu cette liste, vous pensez sans doute à deux choses.

  1. Ça fait beaucoup de conteneurs. Quelle est la différence ? Qu’est-ce que ça change pour moi ? (Réponse courte : les services de conteneur.)
  2. Attendez une minute. Certains ne sont-ils pas identiques ? Les pages LAB ne sont-elles pas juste Lightning Experience ? Pourquoi Visualforce est-il son propre conteneur, et quelle est la différence avec LC4VF ? (Réponse courte : cela fonctionne comme des poupées russes.)

Services de conteneur

Souvenez-vous, un conteneur est un contexte d’application ou un environnement dans lequel votre code est exécuté. Des environnements différents offrent des services différents.

Par exemple, le conteneur one.app (Lightning Experience et l’application Salesforce) offre un certain nombre de services, comme la gestion des événements pour accéder à un enregistrement, créer ou modifier un enregistrement, ouvrir une URL, etc.

D’autres conteneurs n’offrent pas ces services. Un composant qui a besoin des services d’un conteneur ne fonctionnera pas dans un conteneur différent qui ne dispose pas des mêmes services. Par exemple, si vous utilisez l’événement force:createRecord pour créer de nouveaux enregistrements, votre composant fonctionnera très bien dans Lightning Experience, mais si vous l’utilisez dans une application autonome ou dans Lightning Out, il cessera de fonctionner, car rien ne sera en mesure de gérer cet événement.

Si un arbre tombe dans une forêt et qu’il n’y a personne pour l’entendre, fait-il du bruit ? Nous laissons cette question aux philosophes.

Si vous déclenchez un événement dans un conteneur et que rien ne l’écoute, a-t-il un effet ? Voilà une question à laquelle nous pouvons répondre : Non.

Au-delà des concepts de base

Quelle est la solution ? Écrire votre propre service de conteneur pour créer des enregistrements, ainsi qu’un gestionnaire d’événements pour repérer l’événement force:createRecord et le diriger vers votre service client.

Si cela semble fastidieux, c’est parce que c’est le cas. Offrir des services de conteneur robustes est difficile. Des équipes entières d’ingénieurs s’y consacrent à plein temps. Vous arriverez jusqu’à cette question très avancée. En attendant rendez-vous sur AppExchange si vous avez besoin de services à utiliser en dehors de Lightning Experience ou l’application Salesforce.

Nous n’avons pas la place ici pour fournir la liste complète des services de chaque conteneur. Lisez la documentation des fonctionnalités que vous souhaitez utiliser et guettez les avertissements de ce type :

Cet événement est traité par le conteneur one.app. Il est uniquement pris en charge dans Lightning Experience et l’application Salesforce.

Des conteneurs dans des conteneurs (« les poupées russes »)

Un conteneur a des limites. Des murs. Des barrières. Un conteneur garde son contenu à l’intérieur, et le reste à l’extérieur.

C’est la même chose pour les conteneurs d’application. Avec les applications Web et les frameworks, les limites sont souvent un iframe HTML qui est mis en œuvre par le navigateur. Le code à l’intérieur de l’iframe ne peut pas accéder directement aux éléments situés en dehors de l’iframe.

Il y a d’autres sortes de limites. Par exemple, le conteneur lui-même peut créer une frontière en enfermant les événements qui sont déclenchés à l’intérieur.

Voici la partie sympa. Vous pouvez mettre les petits conteneurs dans les grands pour créer des « couches » dans la hiérarchie d’isolation. Les poupées russes, ou matriochkas, représentent parfaitement les conteneurs d’application des composants Aura. Des conteneurs contenant des conteneurs contenant des conteneurs…

Vous pouvez avoir des composants Aura (4) exécutés sur une page Visualforce (3) à l’aide de LC4VF. Ensuite, Vous pouvez ajouter cette page Visualforce à Lightning Experience. Vous obtenez trois conteneurs. Ou vous pouvez utiliser LAB pour ajouter la page Visualforce à une page Lightning (2), puis ajouter cette page Lightning à Lightning Experience (1). Vous obtenez quatre conteneurs. Et il n’est pas difficile d’aboutir à cinq, voire six couches de conteneurs.

Ce qu’il faut retenir : le code de votre composant Aura peut accéder uniquement aux services du conteneur dans lequel il est exécuté, même si ce conteneur se trouve dans un autre conteneur.

Qu’en est-il du composant Aura sur une page Visualforce ? Il ne peut pas déclencher d’événement Lightning Experience fonctionnel, parce que le conteneur Visualforce ne comprend pas ces événements et ne les transmet pas à son propre conteneur, même si vous ajoutez la page Visualforce à Lightning Experience. L’iframe qui sépare Visualforce et Lightning Experience bloque ces événements.

En bref : votre composant peut uniquement compter sur les services du conteneur dans lequel il est exécuté. Si vous créez un composant pour plusieurs contextes, vous aurez besoin de coder des solutions correspondant à chaque ensemble de services. Lisez Des composants Lightning dans Visualforce avec Lightning Out pour voir un exemple de cette technique.