Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Découverte des concepts du code

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • Faire le rapprochement entre les concepts fondamentaux de Visualforce et des composants Aura, tels que les contrôleurs et les requêtes
  • Éviter l’erreur de syntaxe n°1 dans le code des composants Aura
  • Expliquer l’avantage des composants à couplage léger, et la manière de parvenir au couplage léger.

Concept : Contrôleurs

Enfin ! Un concept avec un nom qui ne vous est pas inconnu !

Toboggan ! Malgré ce nom familier, votre expertise Visualforce ne peut pas être appliquée aux composants Aura. L’une des fonctionnalités les plus importantes de Visualforce est le contrôleur standard. En définissant un attribut pour une page, vous pouvez la lier à un type sObject et lui conférer automatiquement de nombreux comportements (lire et écrire des données d’enregistrement, par exemple) sans avoir à écrire de code. Avec le contrôleur standard, beaucoup de non-programmeurs sont capables de créer des pages Visualforce entièrement personnalisées. Il n’existe rien de tel pour les composants Aura. Créer un composant capable d’utiliser des enregistrements exige d’écrire du code.

Et les contrôleurs Visualforce personnalisés ? Ils impliquent d’écrire son propre code. En quoi peuvent-ils être différents des contrôleurs de composants Aura ? Toboggan !

D’abord, rappelez-vous que les contrôleurs Visualforce sont exécutés côté serveur, alors que les contrôleurs des composants Aura sont exécutés côté client. Et parfois côté serveur aussi. Les contrôleurs Visualforce sont écrits en Apex, alors que les contrôleurs des composants Aura sont écrits en JavaScript. Et parfois aussi en Apex.

Architecture du contrôleur Visualforce Architecture du contrôleur des composants Aura
Architecture du contrôleur Visualforce Architecture du contrôleur des composants Lightning

Comme le montre l’illustration, l’architecture des deux contrôleurs est différente. Cette différence, le contrôleur côté client, a une incidence sur le code que vous devrez écrire. Le code de votre contrôleur de composants Aura est exécuté côté client, alors que les données sont stockées sur le serveur. Sans cache, vous devez faire une requête vers le serveur à chaque fois que vous avez besoin de nouvelles données. Vous n’écriviez sans doute pas ce genre de code dans vos contrôleurs Visualforce. De plus, les requêtes à distance sont écrites dans un style asynchrone basé sur des fonctions de rappel, qui diffère sans doute beaucoup du code existant de votre contrôleur.

Par ailleurs, beaucoup d’extensions et de contrôleurs Visualforce personnalisés utilisent les classes Apex StandardController ou StandardSetController pour étendre le comportement standard, au lieu de le remplacer. Hélas, ces classes sont intimement liées à Visualforce. Vous ne pouvez pas les réutiliser dans le code du contrôleur côté serveur de vos composants Aura. Encore du code que vous devrez écrire vous-même.

Échelle ! Toutefois, nous avons une bonne nouvelle pour vous. Si vous créez vos pages Visualforce à l’aide de JavaScript Remoting et des méthodes @RemoteAction Apex, vous concevez déjà votre code de contrôleur d’une manière fortement réutilisable dans des composants Aura. Vous devrez mettre à jour le code existant, mais vous êtes déjà passé à la nouvelle architecture.

Échelle ! Pour finir, voici une vraie bonne nouvelle. Lightning Data Service (LDS) n’est disponible qu’avec les composants Aura. C’est ce qui ressemble le plus à un contrôleur standard dans les composants Aura. Il implique quand même d’écrire du code. Pas autant qu’un contrôleur complet, mais quand même. Mais LDS est nettement plus puissant, et il possède un cache intégré, des notifications de mise à jour et d’autres fonctionnalités sensationnelles. Une fois que vous aurez franchi le pas, vous ne pourrez plus revenir en arrière. Rendez-vous dans la section Ressources pour en savoir plus sur LDS.

Concept : Actions

Dans Visualforce, une action est une méthode de contrôleur qui renvoie une PageReference lorsqu’elle se termine. Une action est généralement liée à un bouton ou à un lien, et représente la tâche que l’utilisateur demande à l’application, suivie par une navigation vers la page suivante ou celle des résultats, ou simplement un retour vers la page d’accueil. Par exemple, un bouton de modification appelle une méthode d’action qui charge des données d’un enregistrement, puis redirige vers une page avec un formulaire de modification.

Échelle ! Les actions des composants Aura sont similaires. Les actions sont des fonctions que vous écrivez en JavaScript et que vous liez à des éléments de l’interface utilisateur. Enfin une échelle !

Pas si vite. Il y a des différences importantes, et si vous les manquez, vous allez tomber au lieu de monter l’échelle.

D’abord, il faut comprendre que les actions ne sont pas des appels de fonction ou de méthode directs, que ce soit dans Visualforce ou dans les composants Aura. Ce n’est pas vous qui les appelez, c’est le framework qui les invoque au bon moment. Jusqu’ici, rien ne change.

Mais dans Visualforce, vos actions sont des méthodes définies par rapport à une classe Apex. Vous avez accès à l’infrastructure du langage autour de votre méthode, notamment des variables d’instance et des méthodes d’instance et de classe.

Toboggan ! Les actions des composants Aura ne sont pas définies dans une classe. Ce sont des définitions de fonction déclarées côté valeur (à droite en notation littérale objet) dans les éléments d’un objet JavaScript contenant des paires nom:valeur. Voici un exemple simple :
({
    myAction : function(component, event, helper) {
        // add code for the action
    },
})

Cette différence de style de déclaration a des conséquences syntaxiques et structurelles. Du point de vue de la syntaxe, remarquez la virgule qui suit la déclaration de fonction (ligne 4). Séparez les gestionnaires d’action par des virgules ! En Apex, ce serait une erreur de syntaxe. En notation littérale objet, oublier la virgule entre deux actions est une erreur de syntaxe. Notez que l’oubli d’une virgule est une erreur qui peut être difficile à repérer. Prenez donc l’habitude de toujours séparer vos gestionnaires d’action par des virgules.

Conseil

Conseil

Si vous utilisez un éditeur externe qui autorise les plug-ins, pensez à ajouter un outil de validation du code JavaScript comme ESLint à votre environnement. Comme c’est une erreur de syntaxe JavaScript, à peu près tous les outils de type lint la repéreront avant que vous n’ayez le temps d’aller deux lignes plus loin.

Ces différences structurelles empêchent le code du contrôleur d’accéder à d’autres fonctions ou valeurs situées dans la ressource contrôleur. Vous ne pouvez pas déclarer de méthode d’assistance dans le contrôleur, vous ne pouvez pas créer de propriétés d’instance ou statiques, etc. Placez plutôt du code réutilisable dans l’assistant associé, et stockez les valeurs d’instance sous forme d’attributs de votre composant. Examinons maintenant ce dernier point plus en détail.

Concept : Propriétés, attributs et « expandos »

Les propriétés Apex sont (fondamentalement) des variables d’instance reposant sur une logique personnalisée. Lorsque vous les définissez dans un contrôleur ou une extension Visualforce, les expressions de la page peuvent les utiliser. Si récupérer et définir une propriété d’un composant ne devrait pas avoir d’effet secondaire (en informatique, on désigne cela par le terme « idempotent »), les propriétés peuvent appeler des méthodes d’assistance pour partager ou abstraire leur logique sous-jacente. Les propriétés sont très utiles (et fréquentes) dans les contrôleurs Visualforce.

Bien que vous auriez peut-être envie de créer des propriétés similaires dans le fichier du contrôleur JavaScript de votre composant Aura, c’est impossible. Vous pouvez essayer de les ajouter à l’assistant, ce qui aura peut-être l’air de marcher. Cependant, l’assistant est un singleton, partagé par toutes les instances de votre composant. Il est plutôt comme une variable de classe statique et vous ne pouvez pas l’utiliser pour enregistrer l’état d’un composant individuel.

Alors, que faire ?

Component Attributes

Si vous devez accéder à la valeur dans une expression du balisage de votre composant, utilisez un attribut de composant. Un attribut de composant est déclaré de la manière suivante.
<aura:attribute name="myAttribute" type="Integer"/>
Les attributs de composant nécessitent au minimum un nom et un type de données. (Il existe des attributs optionnels pour les valeurs par défaut, etc.) Pour faire référence à l’attribut dans le balisage, utilisez la syntaxe des expressions standard.
{!v.myAttribute}
(Nous parlerons plus longuement des expressions et de leur syntaxe dans le prochain module.)

Pour obtenir et définir la valeur de l’attribut dans le code JavaScript de votre contrôleur, utilisez les méthodes get et set. Utilisez les fonctions get et set pour obtenir et définir les valeurs des attributs du composant

Les méthodes get et set sont des fonctions disponibles via le paramètre de composant fourni à la fonction gestionnaire d’action myAction.
({
    myAction : function(component, event, helper) {
        var counter = component.get("v.myAttribute");
        counter++;
        component.set("v.myAttribute", counter);
    },
})
Ici, get (ligne 3) récupère la valeur de l’attribut de composant myAttribute et l’affecte à la variable locale counter. counter est incrémentée, puis set (ligne 5) met à jour l’attribut du composant.

Si vous ne voulez pas que d’autres composants puissent influer sur la valeur de l’attribut de votre composant, déclarez l’attribut comme private. Sinon, l’attribut est intégré à l’API publique de votre composant.

Expandos JavaScript et attributs privés

Les attributs, avec tout le cérémoniel get/set qu’ils imposent, paraissent parfois bien formels aux développeurs Visualforce. Si vous êtes à l’aise avec JavaScript, vous pouvez essayer d’utiliser une des particularités du langage en définissant une valeur sur l’instance du composant à partir d’une fonction d’action.

component._myExpando = "A new string variable";

Cet expando, créé à la volée, fait désormais partie de l’instance de votre composant. Il ressemble à une jolie variable d’instance toute légère.

Le problème est que les expandos ouvrent la porte à des bugs subtils et autres fuites de mémoire. Ils fonctionnent, mais ils causeront probablement des problèmes. C’est pourquoi nous vous recommandons de les éviter. Ici, l’approche recommandée consiste à créer un attribut de composant, puis à paramétrer son niveau d’accès sur private (nous recommandons également de faire précéder le nom des attributs privés d’un trait de soulignement (par exemple _myAttribute) pour bien signaler qu’il s’agit de variables privées).

Concept : Appels de méthode ou événements

Pour finir ce module, un dernier grand concept.

Vos pages Visualforce fonctionnent (probablement) grâce à des méthodes. Les expressions, les propriétés et les actions sont toutes, en fin de compte, des appels de fonction. Les appels de fonction (ou de méthode) sont faciles à repérer : elles sont déclarées dans la classe Apex du contrôleur. Il est facile de suivre l’ordre d’exécution et de comprendre leur comportement. (Certes, « facile » est un terme relatif. Faisons comme si.)

Les appels de méthodes représentent également un couplage fort entre les différentes parties de votre application. Votre page est fortement couplée à son contrôleur et ses extensions, qui peuvent être elles-mêmes couplées à d’autres classes Apex. La relation entre les différentes pièces est facile à suivre, mais potentiellement fragile ou difficile à réutiliser.

Les composants Aura ont été conçus pour remédier à certaines des limitations de Visualforce. Plus particulièrement, les composants utilisent (en théorie) un couplage léger. Le mécanisme employé pour ce couplage léger repose sur les événements.

Comparez une méthode à une « ligne physique » entre l’émetteur et le récepteur de l’appel. Lorsqu’on appuie sur le bouton à une extrémité, la lumière s’allume à l’autre. Un câble physique permet d’avoir plusieurs appareils sur le même circuit, mais si vous allumez dans le couloir, elle s’allume aussi dans le placard. Il en va de même pour les logiciels : plus vous réutilisez de parties fortement couplées d’un système, plus vous rencontrez d’effets secondaires, et plus il est difficile d’intégrer de nouvelles pièces.

Utiliser les événements pour communiquer entre les composants Aura crée des connexions « sans fil ». Appuyer sur un interrupteur (lancer un événement) envoie un signal radio. Si quelqu’un (un autre composant) est à l’écoute sur cette fréquence (dispose d’un gestionnaire pour cet événement), il peut agir lorsqu’il reçoit le signal. Cependant, depuis votre émetteur, vous ne pouvez pas savoir si quelqu’un est à l’écoute. De même, vous écrivez votre composant de manière à ce qu’il se comporte correctement, que son événement soit reçu et traité ou non.

La métaphore commence à s’épuiser un peu. Voici donc plutôt quelques conseils pour conclure.

  • Laissez une chance et un peu de temps aux principes de composition et de couplage léger, et vous deviendrez un meilleur développeur. C’est une approche différente de celle dont vous avez l’habitude avec Visualforce. Certains diront qu’elle est plus difficile, mais nous croyons que c’est une question d’apprentissage et d’expérience.
  • Ne traitez pas les méthodes comme vous le feriez dans Visualforce. Vous découvrirez tôt ou tard que vous pouvez publier et appeler vos méthodes dans vos composants Aura. Il est tentant de revenir à ce qu’on connaît lorsqu’on tombe sur un problème de conception. Résistez à la tentation. L’utilisation des méthodes de composant Aura peut se justifier. Utilisez-les quand elles constituent le meilleur outil. N’en faites pas le fameux marteau qui fait ressembler tous les problèmes à des clous.