Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Découverte des paquets et du cycle de vie des requêtes

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • Expliquer la différence entre une page Visualforce et un paquet de composants Aura, ainsi que la façon dont chacun d’eux est représenté dans les ressources, à la fois localement et sur Salesforce
  • Expliquer les différences de base du cycle de vie des requêtes Visualforce et celui des composants Aura, et indiquer où le code des composants est exécuté

Concepts de base

Dans ce module, nous étudierons les concepts et fonctionnalités de Visualforce et présenterons leur équivalent le plus proche dans les composants Aura. Tous n’auront pas d’équivalent direct. Visualforce et Aura présentent des différences fondamentales en matière d’architecture et d’exigences sur la façon de les utiliser pour créer des applications. Nous expliquerons autant de différences que possible, en nous repérant grâce aux fonctionnalités individuelles.

Vous remarquerez que nous ne détaillons pas ici la façon d’utiliser les fonctionnalités des composants Aura. (Ça, c’est le rôle du module Bases des composants Aura.) Nous nous concentrerons plutôt sur la clarification des différences essentielles de manière à vous éviter d’être systématiquement piégé par des éléments qui portent des noms sont similaires.

Concept : Page ou paquet

Avant d’aborder des concepts abstraits, penchons-nous sur quelque chose d’assez concret : comment une page ou un composant est stocké sur Salesforce.

Le stockage sur Salesforce des pages Visualforce (et des composants Visualforce, mais nous nous pencherons sur eux plus tard) s’effectue sous la forme d’une entité unique, l’ApexPage. Si vous utilisez les extensions Salesforce pour Visual Studio Code ou un autre outil pour copier vos pages Visualforce vers votre emplacement de stockage local et travailler dessus, chaque page Visualforce y est représentée par deux fichiers dans le répertoire metadata/pages :

  • votreNomDePage.page
  • votreNomDePage.page-meta.xml

Le premier contient le code de la page, et le second ses métadonnées (version de l’API, réglages pour mobile, etc.).

Même s’il peut y avoir des dépendances vers d’autres artefacts tels qu’un contrôleur Apex ou une extension, des ressources statiques, etc., elles sont séparées de la page. Votre page y fait référence mais ne les inclut pas.

Un composant Aura est plus complexe qu’un seul élément de code et des métadonnées : aujourd’hui il peut inclure jusqu’à huit éléments de code et les métadonnées (neuf éléments au total). C’est la raison pour laquelle chaque composant est stocké dans un paquet comportant des ressources. Ce paquet est représenté par un dossier de fichiers lorsque vous l’enregistrez dans votre emplacement de stockage local. Un composant complexe pourrait ressembler à ceci : Exemple d’un paquet de composant

Nous aborderons des ressources les plus importantes du paquet du composant tout au long de la suite de ce module. Pour le reste, référez-vous aux informations contenues sur la page Paquets de composants et dans d’autres parties du Guide du développeur de composants Aura Lightning.

Échelle ! Suivez ces étapes pour créer un ensemble de composants Aura dans Visual Studio Code avec les extensions Salesforce installées :
  1. Appuyez sur Commande + Maj + P sur un Mac ou sur Ctrl + Maj + P sur un ordinateur Windows ou Linux pour ouvrir la palette de commandes.
  2. Créez un projet dans la palette de commandes à l’aide de SFDX:Create Project.
  3. Créez un paquet de composants dans la palette de commandes à l’aide de SFDX:Create Aura Component. RemarqueDans le défi pratique de cette unité, vous autoriserez Visual Studio Code à déployer des fichiers dans votre organisation. Pour cela, vous devrez connaître le nom d’utilisateur et le mot de passe de votre organisation. Pour obtenir votre nom d’utilisateur et votre mot de passe Trailhead Playground, reportez-vous au module Gestion des Trailhead Playgrounds.
    Pour en savoir plus, consultez le module Compétences et outils pour composants Aura.

Concept : Côté client ou côté serveur

C’est l’un des deux points « évidents ». Qu’est-ce qui nous fait dire ça ? Il faut être clair sur ce que ces termes veulent dire et sur leurs implications.

Visualforce classique est exécuté « côté serveur ». Cela signifie que quand une page est demandée, un serveur Salesforce traite le balisage, et que le HTML ainsi produit est envoyé au navigateur de l’utilisateur qui souhaite l’afficher. Si la page comprend une expression (vous savez, ce qu’on trouve entre les délimiteurs « {! } »), elle est évaluée par le serveur. Les références à des variables globales sont résolues sur le serveur. Si la page accède à une propriété du contrôleur, elle est également traitée sur le serveur. et ainsi de suite. Considérons pour le moment que tout le « traitement du framework » a lieu sur le serveur. (Nous mettons de côté l’utilisation de Visualforce + JavaScript Remoting utilisé comme simple conteneur pour une application JavaScript. Dans ce cas vous n’utilisez pas réellement Visualforce, excepté comme serveur Web.)

Pour les composants Aura, c’est inverse. Lorsqu’un composant est demandé, les ressources du composant sont préparées et envoyées au navigateur de l’utilisateur qui a fait la requête. C’est majoritairement du JavaScript, avec du balisage pour le structurer. Le navigateur exécute le JavaScript, ce qui produit du HTML et l’insère dans la « page » existante. (Nous expliquerons bientôt ces guillemets.) L’évaluation des expressions, les variables globales, les propriétés du contrôleur, etc., sont toutes résolues sur le client.

Cycle de requête Visualforce Cycle de requête des composants Aura
Cycle de requête Visualforce Cycle de requête des composants Lightning
  1. L’utilisateur demande une page
  2. Le serveur exécute le code sous-jacent de la page et envoie le code HMTL résultant vers le navigateur
  3. Le navigateur affiche le code HTML
  4. Lorsque l’utilisateur interagit avec la page, revenez à la première étape.
  1. L'utilisateur demande une application ou un composant
  2. Le paquet de composants ou l'application sont renvoyés au client
  3. Le navigateur charge le paquet
  4. L'application JavaScript génère l'interface utilisateur
  5. Lorsque l'utilisateur interagit avec la page, l'application JavaScript modifie l'interface utilisateur selon les besoins (retour à l'étape précédente)

Cette différence architecturale fondamentale a des conséquences importantes. Par exemple, votre composant peut interagir avec un utilisateur sans faire de nouvelle requête au serveur, mais si votre composant a besoin d’enregistrer ou de charger de nouvelles données, il doit faire une requête au serveur.

Ça semble clair, même évident. Souvenez-vous cependant qu’en Visualforce classique, cette interaction serait accompagnée d’une nouvelle requête de page visible et d’un rechargement. Avec un composant Aura, l’interaction de l’utilisateur avec le JavaScript côté client paraît plus « vivante » et plus réactive. Ainsi, lorsqu’il faut charger de nouvelles données, la latence d’une requête serveur peut sembler soudainement lente, même si l’expérience dans son ensemble prend moins de temps qu’une requête Visualforce !

Vous constaterez que les composants Aura ont globalement de bonnes performances. Cependant, si vous ne prenez pas garde à vos requêtes vers le serveur et à la façon dont elles affectent l’expérience utilisateur, vos utilisateurs pourront trouver que l’application est « lente ».

Nous aborderons d’autres aspects de cette distinction dans les prochains sujets, mais vous devez avoir une idée claire du fonctionnement client/serveur concernant le comportement des frameworks.