• Accueil / Salesforce / 6 Considérations relatives…
, 6 Considérations relatives à l&rsquo;ingénierie des composants Web Lightning (LWC)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

6 Considérations relatives à l’ingénierie des composants Web Lightning (LWC)13 minutes de lecture


Dans mon travail quotidien, je travaille principalement avec Aura et Visualforce – les deux ont leurs propres versions de composants. Pour affiner mes compétences en Lightning Web Component (LWC), j’ai construit quelques composants pour me familiariser avec certains des principes fondamentaux du nouveau paradigme de développement de composants.

Si vous y réfléchissez à distance, Visualforce, Aura et LWC essaient tous de résoudre les mêmes problèmes du point de vue de l’utilisateur final. Pourtant, ils diffèrent grandement par des détails techniques, c’est pourquoi j’ai voulu explorer des problèmes tels que l’internationalisation, la saisie des utilisateurs ou la gestion des erreurs, car ce sont des aspects centraux.

, 6 Considérations relatives à l&rsquo;ingénierie des composants Web Lightning (LWC)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

Dans cet article, nous examinerons six sujets en particulier. Ils couvriront tous les aspects mentionnés et devraient aider à donner un aperçu sur la façon de traiter chacun d’eux :

  • Cycle de vie des composants
  • 3 façons de travailler avec CSS et styles
  • Gestion générique de nombreux champs de saisie
  • Exceptions Apex
  • Étiquettes personnalisées
  • Choses pas encore disponibles dans LWC

Voilà pour une introduction, plongeons directement dans quelques exemples et code. Juste pour être sûr que nous sommes sur la même longueur d’onde, je parlerai beaucoup des parents et des enfants, donc je pense qu’une explication pourrait être utile :

L’idée derrière tout type de composant est de vivre à l’intérieur (et à côté) d’autres composants. Si un composant réside à l’intérieur d’un autre composant, il est considéré comme un enfant. Un composant contenant un autre composant est considéré comme un parent. Un composant peut être à la fois un enfant et un parent.

1. Mise en pratique de tous les hooks du cycle de vie des composants

Une question fondamentale sur les parents et les enfants dans les composants est : qui vient en premier ? Parent ou enfant ? LWC se range du côté de la « manière intuitive » (comme Visualforce) : les parents sont instanciés d’abord, puis les enfants. Si vous avez grandi avec Aura sur la plate-forme, vous êtes habitué à un cycle de vie des composants complètement différent – Aura s’initialise les enfants d’abord, entre autres choses.

D’autres questions importantes sont : quelle est la première opportunité pour mon propre code de s’exécuter dans l’ensemble du cycle de vie ? Et qu’est-ce qui est disponible pour mon code d’implémentation et quand ? En termes de LWC : quels crochets de cycle de vie existent et quelles propriétés privées ou publiques sont accessibles dans chacun ?

Ceci, bien sûr, est expliqué et visualisé dans le documentation développeur:

, 6 Considérations relatives à l&rsquo;ingénierie des composants Web Lightning (LWC)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

Si, comme moi, vous apprenez en faisant, de tels organigrammes ont plus de sens après avoir construit quelques composants. Étant donné que le cycle de vie des composants est si vital, je vous encourage à suivre cette étape par ici, en tirant la console vers le haut – ne vous y habituez pas, cependant, tous les autres composants de cet article doivent s’exécuter dans Salesforce et sont disponibles sur GitHub.

Mon premier exemple de composant est un simple conteneur pour deux instances du même composant enfant. Les enfants tirent parti des getters et setters publics et impriment le jour de la semaine en cours et le jour de la semaine suivant. Vous pouvez masquer la partie suivante du jour de la semaine via un bouton. Le composant a à peu près la structure suivante :


Dans le code du composant, pour chaque hook de cycle de vie de composant comme connectedCallback() ou renderCallback(), les mêmes choses se produisent : nous vérifions l’accès aux propriétés ou aux composants enfants et affichons où nous sommes et ce que nous pouvons faire à la console.

Voici le résultat :

, 6 Considérations relatives à l&rsquo;ingénierie des composants Web Lightning (LWC)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

Étant donné que les LWC sont fondamentalement Cours Javascript, le constructeur des classes s’exécute avant toute autre chose. Une tentative d’accès aux composants enfants ou aux propriétés publiques dans le constructeur échoue. Avant que cela ne devienne trop verbeux, voici le résumé de ce qui se passe quand et de ce que vous pouvez/ne pouvez pas faire dans chaque partie.

  • Le constructeur parent s’exécute en premier :
    • Pas d’accès aux composants enfants ou aux propriétés publiques
    • Accès aux propriétés privées
    • Accès aux importations
    • Accéder au document
  • Parent ConnectedCallback s’exécute – cela signifie que le parent est inséré dans le DOM (« structure de la page Web », en quelque sorte):
    • Pas d’accès aux composants enfants
    • Accès aux propriétés publiques
    • Accès aux importations
    • Accéder au document
  • Constructeur Child1
  • Child1 ConnectedRappel
  • Enfant1 Getters
  • Child1 RenderedCallback
  • Constructeur Child2
  • Child2 ConnectedCallback
  • Obturateurs Child2
  • Child2 RenderedCallback
  • Rappel rendu parent :
    • Accès à tous les composants

Les propriétés publiques sur les enfants sont définies une fois qu’ils ont été connectés avec succès au DOM. Le parent rendu et terminé en dernier – seulement après que tous les enfants ont été créés avec succès.

Mais que se passe-t-il si quelque chose ne va pas avec l’un des enfants ? C’est là qu’intervient et voici ce qui se passe : sans errorCallback(), le framework lève une exception pour vous et l’exécution s’arrête – plus rien ne se passe.

Avec un errorCallback(), le parent est rendu vide, ce qui signifie que le renderCallback() est exécuté après le errorCallback(). Cela laisse de la place pour gérer une erreur plus gracieusement si vous le souhaitez.

, 6 Considérations relatives à l&rsquo;ingénierie des composants Web Lightning (LWC)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

2. Ajout de styles par programmation

Je suis un grand fan de système de conception de foudre (SLDS) car il supprime les frictions de l’expérience de l’utilisateur final et offre des conseils exceptionnels sur la façon dont un composant doit se comporter et apparaître. Le système de conception couvre une grande variété de besoins de style – rembourrages et marges et bien d’autres – sans avoir à créer notre propre CSS personnalisé.

Si le style dépend de l’entrée de l’utilisateur ou doit être déterminé par programmation, il existe trois façons d’y parvenir. Supposons le LWC suivant et que nous voulons donner à la section un fond rouge :


Appliquer une classe CSS existante

Cela signifie que vous avez déjà une classe en tête que vous souhaitez appliquer à un élément. C’est soit à partir de SLDS, soit dans votre fichier CSS personnalisé :

.red-background {
background-color: red;
}

Dans les deux cas, vous pouvez utiliser le code suivant dans le renderCallback pour atteindre votre objectif :

renderedCallback() {
let section = this.template.querySelector("section");
section.classList.add("red-background");
}

Utiliser l’attribut style dans le balisage

L’attribut style sur les éléments HTML facilite la transmission d’une chaîne en tant qu’instruction de style. Soyez prudent car cela peut gâcher du CSS soigneusement conçu, mais c’est tout à fait acceptable dans des cas d’utilisation simples si vous contrôlez le contenu de {computedStyle}.


connectedCallback() {
this.computedStyle=`background-color: red;`
}

Appliquer les propriétés CSS par programme

Si nous voulons utiliser un sélecteur de couleurs pour permettre aux utilisateurs finaux de choisir leur propre couleur, alors l’utilisation de variables CSS est la solution. Avec chaque variable CSS, nous pouvons également définir une valeur de repli :

.dynamic-background {
background-color: var(--background-color, red); 
}

Et dans votre fichier Javascript :

connectedCallback() {
const css = document.body.style;
css.setProperty("--background-color", "green");
}

3. Comment gérer de nombreux champs de saisie

Parfois, nous ne pouvons pas nous fier à un formulaire de modification d’enregistrement éclair, car les entrées que nous voulons créer ne dépendent pas d’un enregistrement Salesforce. Par souci de simplicité, nous créons un exemple avec un tas de champs de texte :

L’astuce – ou plutôt la convention – est de s’appuyer sur le nom d’entrée pour être également le nom de votre propriété. Ensuite, vous pouvez câbler quelque chose comme ceci :

import { LightningElement } from "lwc";
export default class ManyInputs extends LightningElement {
inputs = ["textOne", "textTwo", "textFour", "textFive", "textSix"];
onInputChange(event) {
this[event.target.name] = event.detail.value;
console.log(`Value for textOne: ${this.textOne}`);
console.log(`Value for textTwo: ${this.textTwo}`);
// ...
}

4. Mythes autour de la gestion des exceptions

La meilleure pratique pour envoyer des exceptions au client reste les AuraHandledExceptions (pour des raisons de sécurité, j’expliquerai pourquoi, sous peu) et je me suis toujours demandé quelles étaient les différences entre une exception système, une exception personnalisée ou une AuraHandledException du point de vue d’un navigateur/client .

Si vous recherchez google Aura Handled Exception, vous vous retrouvez dans la partie Aura de la documentation et cela vous amène à un article de Philippe Ozil qui a également été écrit pour Aura et est maintenant complètement obsolète. Non seulement en ce qui concerne les changements dans LWC – comme le article de suivi par Aditya Naag Topalli suggère. De quoi s’agit-il ? Malheureusement, rien.

Pour faire court, il n’y a qu’une toute petite différence entre une AuraHandledException, une Custom Exception ou une System Exception.

Une AuraHandledException n’envoie aucune information de trace de pile au client. Donc, si vous craignez particulièrement que le client ne connaisse aucun détail d’implémentation côté serveur – ce qui peut être un problème de sécurité – alors AuraHandledException est la voie à suivre pour LWC et Aura. Dans les deux paradigmes, vous devrez gérer les exceptions manuellement – aucun message ne s’affichera automatiquement en cas d’erreur liée au serveur. Ce service contextuel d’erreur n’existait que pour Aura et a complètement cessé d’exister avec l’avènement de LWC.

Pour jouer avec Exception dans Aura et LWC, veuillez vous référer au composant de démonstration sur GitHub.

, 6 Considérations relatives à l&rsquo;ingénierie des composants Web Lightning (LWC)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

Assurez-vous également de vérifier ceci composant utilitaire de la démo de recettes LWC. Les erreurs Apex ne sont pas le seul type d’erreurs qui peuvent se produire. Différentes API de LWC et/ou de navigateur offrent des réponses d’erreur quelque peu différentes. L’utilitaire permet d’extraire les parties pertinentes pour toutes sortes d’objets d’erreur.

5. Désencombrer les étiquettes personnalisées

L’un des avantages des LWC est leur connaissance des métadonnées. Si vous importez une étiquette personnalisée pour la prise en charge multilingue dans votre composant, l’étiquette personnalisée ne peut pas être supprimée tant qu’elle est référencée dans le fichier Javascript LWC.

Voici l’inconvénient : en tant qu’éditeur de logiciels indépendant, j’ai beaucoup, beaucoup d’étiquettes dont il faut s’occuper. Dans Visualforce et Aura, j’ai un accès direct aux étiquettes dans la partie balisage/html du composant respectif. Dans LWC, je dois importer chaque étiquette seule et accrocher cette importation dans une propriété :

import { LightningElement } from "lwc";
import CUSTOMLABEL from "@salesforce/label/CustomLabelDemo";
export default class CustomLabelDemo extends LightningElement {
customLabel = CUSTOMLABEL;
}

Et puis utilisez cette propriété dans la partie balisage/HTML du LWC :


Il n’y a aucun moyen de contourner cela et, si vous avez de nombreuses étiquettes personnalisées comme moi, cela devient encombrant.

Afin de garder au moins l’en-tête de classe court et net et d’éviter de l’encombrer avec des étiquettes personnalisées, nous utilisons un fichier labels.js supplémentaire par composant, qui réside dans le dossier du composant et peut être généré automatiquement à partir, par exemple, d’un fichier CSV. Voici à quoi cela ressemble :

import label1 from "@salesforce/label/c.label1";
import label2 from "@salesforce/label/c.label2";
import label3 from "@salesforce/label/c.label3";
export const customLabels = {
label1,
label2,
Label3
};

Nous utilisons le nom de l’API d’étiquette personnalisée à tous les endroits, dans le composant consommateur, nous n’avons qu’à faire une seule importation :

import { LightningElement } from "lwc";
import { customLabels } from "./labels.js";
export default class CustomLabelDemo extends LightningElement {
labels = LABELS;
}

Cette approche conduit également à une indication claire lorsqu’une étiquette personnalisée est utilisée par opposition à une propriété normale. Tous les libellés personnalisés commencent par : libellés :


6. Hiver 22 : Une restriction majeure (presque) disparue, d’autres toujours en place

Salesforce travaille activement sur une nouvelle architecture de sécurité côté client appelée «Sécurité Web Lightning» – il est actuellement en version bêta publique. Le nouveau moteur nous offrira, entre autres, aux développeurs la possibilité d’utiliser des composants d’un autre espace de noms dans notre propre code de composant. Pensez à Visualforce global ou aux composants Aura globaux – si un AppExchange les fournit, nous pouvons créer notre propre code autour d’eux. Avec Lightning Web Security, les LWC bénéficieront également de cette option.

L’écart d’espace de noms est en train d’être comblé plus de deux ans après la sortie initiale. Ce n’est pas la seule lacune : quelques composants de service ne sont toujours pas disponibles pour LWC. Pour chacun de ces cas d’utilisation, nous devons créer des composants Aura :

  • foudre:utilityBarAPI – permet à un composant d’interagir avec la barre d’utilitaires
  • Lightning:unsavedChanges – permet aux développeurs d’avertir facilement les utilisateurs s’ils souhaitent s’éloigner sans enregistrer
  • foudre:superpositionBibliothèque – un moyen de créer des modaux et plus encore : créez des messages pop over utiles et joliment stylisés
  • Les LWC peuvent être utilisés pour des actions rapides à partir de maintenant, mais ils ne peuvent pas être utilisés pour remplacer actions standards comme « Nouvel enregistrement » ou « Modifier l’enregistrement » pour le moment.

Je suis certain que les dérogations aux actions standard seront éventuellement livrées, mais je ne m’attends pas à ce que les autres arrivent de si tôt.

La sécurité est au cœur d’un autre changement que vous devez connaître. Si vos enfants envoient des CustomEvents avec l’intention d’atteindre leurs parents (ce qui est considéré comme traversant les frontières Shadow DOM), ils doit utiliser composé en plus des bulles :

onButtonClick() {
this.dispatchEvent(
new CustomEvent("importantButtonClickEvent", {
bubbles: true,
composed: true
})
);
}

Sommaire

Nous avons sauté d’un sujet à l’autre d’une manière apparemment rhapsodique, offrant les meilleures pratiques ici et une certaine sagesse là-bas. En fait, nous avons parcouru un terrain sérieux en touchant quelques éléments centraux du développement de composants en général, et LWC en particulier. Non seulement nous en avons appris un peu plus sur le cycle de vie des composants pour les LWC, mais le même modèle peut être utilisé pour se familiariser avec le framework de composants de niveau supérieur que Salesforce pourrait publier à l’avenir. Gestion des entrées, style, erreurs, internationalisation – ce sont tous des sujets centraux pour tout type de développement Web.

Si vous souhaitez vous plonger dans le code ou en savoir plus sur le développement LWC ou Javascript en général, consultez les ressources ci-dessous :



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer