• Accueil / Salesforce / Interactions dynamiques en…
, Interactions dynamiques en hiver 22<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Interactions dynamiques en hiver 225 minutes de lecture


, Interactions dynamiques en hiver 22<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

introduction

Si tout se passe comme prévu, Dynamic Interactions passe en GA à l’hiver 22. Le notes de version avoir ceci à dire
à propos d’eux:

Avec les interactions dynamiques, un événement se produisant dans un composant sur un
La page Lightning, telle que l’utilisateur qui clique sur un élément dans une vue de liste, peut
mettre à jour les autres composants de la page.

Ce qui, à mon avis, le sous-estime beaucoup, comme je vais tenter de l’expliquer dans le
reste de ce post.

Exemple d’application

Vous pouvez trouver le code de l’exemple d’application dans le référentiel Github. Il n’y a pas
un montant énorme, vous choisissez un compte et un autre composant obtient l’identifiant
et Nom du Compte et récupère les Opportunités qui lui sont associées :

, Interactions dynamiques en hiver 22<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Découplage des composants

Ce que les interactions dynamiques nous permettent réellement de faire, c’est d’assembler des
composants dans des interfaces utilisateur personnalisées tout en conservant un contrôle total sur le
disposition. Les composants peuvent provenir de différents développeurs, et nous pouvons ajouter ou
supprimer les composants qui interagissent les uns avec les autres sans avoir à mettre à jour aucun
code source, ou avec les composants ayant la moindre idée de quoi d’autre
est sur la page.

C’est quelque chose que je voulais depuis des années, mais je n’ai jamais pu trouver de solution
cela ne nécessitait pas que mes composants personnalisés sachent quelque chose sur ce qui était
se passe sur la page.

La manière originale de fournir à un utilisateur des composants qui interagissent avec chacun
l’autre était de créer un composant conteneur et d’y intégrer les autres. Les
le conteneur sait exactement quels composants sont intégrés et possède souvent les données
que les autres composants fonctionnent. Il n’y a pas de découplage, et pas d’opportunité
pour changer la mise en page à mesure que vous obtenez le conteneur plus tous ses enfants ou
rien.

Lightning Message Service était le changement de jeu précédent, et cela a permis
composants à être assez faiblement couplés. Ils publieraient des événements quand
quelque chose leur est arrivé, et recevoir des événements quand quelque chose s’est passé
ailleurs sur lesquels ils devaient agir. Ils étaient encore couplés par le
messages qui ont été envoyés et reçus – tout composant qui souhaitait
participer devait connaître les canaux de messages utilisés et faire
sûr qu’ils ont souscrit et publié sur ceux-ci. Bonne chance pour prendre les composants
développé par un tiers et les déposer pour améliorer votre page. Ça faisait
permettre à la disposition d’être facilement modifiée et aux composants, tant qu’ils savaient
sur les chaînes et les messages, à ajouter et à supprimer sans rien changer
code. Je prévoyais un article de blog à ce sujet, mais une inactivité magistrale m’a encore une fois épargné la peine de l’écrire puis d’avoir à produire un autre article déconseillant cette approche

Avec les interactions dynamiques, il suffit que les composants publient
événements lorsque des choses d’intérêt leur arrivent, et exposent les propriétés publiques
qui peuvent être mis à jour lorsque des choses qui devraient les intéresser se produisent, le rêve
de composants découplés est réalisé. Les composants n’ont pas à écouter
pour les événements des uns et des autres, qui sont gérés par la page du générateur d’applications Lightning. Comme
le concepteur de la page, je décide de ce qui doit se passer lorsqu’un
un composant déclenche un événement particulier. Essentiellement, j’utilise le constructeur de page
pour câbler les composants entre eux, par configuration.

Retour à l’exemple d’application

Mon application se compose de deux composants (aucun conteneur nécessaire) :

  • choisir un compte – cela récupère tous les comptes du système et présente
    l’utilisateur avec un combo de foudre pour qu’il puisse en choisir un. Dans la capture d’écran
    ci-dessus, c’est sur le côté gauche. Lorsque l’utilisateur choisit un compte, un
    accountselected CustomEvent est déclenché avec les détails – tous les LWC standard :

        this.dispatchEvent(
                new CustomEvent(
                    'accountselected', 
                    {detail: {
                        recordId: this.selectedAccountId,
                        recordName: this.selectedAccountName
                    }
                })
        );
  • informations de compte – cela récupère les informations d’opportunité pour le recordId
    qui est exposé comme un bien public, encore une fois tout standard et, grâce à
    propriétés réactives, je n’ai pas à intervenir manuellement lorsque l’identifiant
    changements:

    @api get recordId() {
        return this._recordId;    
    }

    set recordId(value) {
        if (value) {
            this._recordId=value;
            this.hasAccount=true;
        }
    }
    
		....
        
    @wire(GetOpportunitiesForAccount, {accountId: '$_recordId'})
    gotOpportunities(result){
        if (result.data) {
            this.opportunities=result.data;
            this.noOpportunitiesFound=(0==this.opportunities.length);
        }
    }

et la dernière étape consiste à utiliser Lightning App Builder pour définir ce qui se passe
lorsque l’événement accountSelected se déclenche. Je modifie la page et clique sur le
composant ChooseAccount, et il y a un nouvel onglet à côté du (manque de)
propriétés qui me permettent de définir des interactions pour le composant – le
Événement de compte sélectionné :

, Interactions dynamiques en hiver 22<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

et je peux alors renseigner les détails de l’interaction :

, Interactions dynamiques en hiver 22<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Dans ce cas, je cible le composant accountInfo et je définis ses propriétés publiques recordId et recordName sur leurs homonymes de l’événement publié. Si j’avais des composants supplémentaires qui se souciaient de la sélection d’un compte, je créerais des interactions supplémentaires pour modifier leur état afin de refléter la sélection.

J’ai maintenant deux composants qui communiquent entre eux, sans qu’aucun d’eux ne sache rien de l’autre, en utilisant des fonctionnalités tout à fait standard. Je peux câbler des composants supplémentaires, les déplacer ou supprimer des composants à volonté.

Conclusion

Je me retrouve régulièrement à produire des interfaces utilisateur hautement personnalisées qui permettent de gérer plusieurs enregistrements sur une seule page. Pour ce cas d’utilisation, les interactions dynamiques ne sont rien de moins qu’un changeur de jeu, et je suis certain que ce sera ma solution de prédilection.

En rapport





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