Types d’événements

Un module de bibliothèque de types d’événement a un seul objectif : détecter lorsqu’une activité se produit et, lorsqu’elle se produit, appeler une fonction pour déclencher la règle associée. Ce qui est détecté dépend de vous. Détectez-vous quand un utilisateur fait un certain geste ? Lorsqu’un utilisateur fait rapidement défiler une page ? Lorsqu’un utilisateur interagit avec quelque chose ?

REMARQUE

Ce document suppose que vous connaissez les modules de bibliothèque et leur intégration dans les extensions Platform Launch. Consultez la présentation du formatage du module de bibliothèque pour une introduction relative à son implémentation avant de revenir à ce guide.

Outre le paramètre settings commun à d’autres types de module, module.exports pour un type d’événement accepte un second paramètre, trigger :

module.exports = function(settings, trigger) { … };
Paramètre Description
settings Objet contenant tous les paramètres configurés par l’utilisateur dans la vue du type d’événement. Vous avez le contrôle ultime sur ce qui va dans cet objet.
trigger Fonction que le module doit appeler chaque fois que la règle doit être déclenchée. Il existe une relation de type « un à un » entre un objet settings, une fonction trigger et une règle. En d’autres termes, la fonction de déclenchement que vous avez reçue pour une règle ne peut pas être utilisée pour déclencher une autre règle.
REMARQUE

La fonction exportée sera appelée une fois pour chaque règle configurée pour utiliser votre type d’événement.

Supposons que l’activité que nous détectons a lieu au bout de cinq secondes. Au bout de cinq secondes, l’activité a lieu et la règle doit se déclencher. Notre module peut se présenter comme suit :

module.exports = function(settings, trigger) {
  setTimeout(trigger, 5000);
};

Que se passerait-il si nous voulions rendre la durée configurable par l’utilisateur d’Adobe Experience Platform Launch ? Dans notre vue, nous autoriserions l’utilisateur à entrer une durée, puis à enregistrer la durée dans l’objet paramètres. L’objet pourrait ressembler à ceci :

{
  "duration": 25000
}

Pour fonctionner selon la durée définie par l’utilisateur, notre module devrait être modifié pour devenir ceci :

module.exports = function(settings, trigger) {
  setTimeout(trigger, settings.duration);
};

Transmission de données d’événement contextuelles

Lors du déclenchement d’une règle, il peut s’avérer utile de fournir des détails supplémentaires sur l’événement qui s’est produit. Les utilisateurs qui créent des règles peuvent trouver ces informations utiles pour obtenir un certain comportement. Supposons, par exemple, qu’un spécialiste marketing souhaite créer une règle dans laquelle une balise d’analyse est envoyée chaque fois que l’utilisateur balaie l’écran. Si notre extension fournit un type d’événement swipe, le spécialiste marketing peut utiliser notre type d’événement pour déclencher la règle de manière appropriée. Maintenant, que se passerait-il si le spécialiste marketing souhaitait inclure sur la balise l’angle spécifique auquel le balayage s’est produit ? Cela serait difficile à faire sans informations supplémentaires.

Pour fournir des informations supplémentaires sur l’événement qui s’est produit, transmettez un objet lors de l’appel de la fonction trigger. Par exemple :

trigger({
  swipeAngle: 90 // the value would be the detected angle
});

Le spécialiste marketing peut alors utiliser cette valeur sur une balise d’analyse en spécifiant la valeur %event.swipeAngle% dans un champ de texte. Il peut également accéder à event.swipeAngle à partir d’autres contextes (comme une action de code personnalisée). N’hésitez pas à inclure toutes les informations sur les événements qui pourraient être utiles à un spécialiste marketing. Ces informations sont entièrement facultatives.

nativeEvent

Si votre type d’événement est basé sur un événement natif (par exemple, si votre extension a fourni un type d’événement click), nous vous recommandons de définir la propriété nativeEvent comme suit :

trigger({
  nativeEvent: nativeEvent // the value would be the underlying native event
});

Cela peut s’avérer utile pour les spécialistes marketing qui tentent d’accéder à des informations provenant de l’événement natif, telles que les coordonnées du curseur.

element

S’il existe une relation forte entre un élément et l’événement qui s’est produit, nous vous recommandons de définir la propriété element sur le nœud DOM de l’élément. Supposons, par exemple, que votre extension fournisse un type d’événement click et que vous autorisiez les spécialistes marketing à le configurer afin que la règle ne se déclenche que si un élément avec l’identifiant de herobanner est sélectionné. Dans ce cas, si l’utilisateur clique sur la bannière principale, il est recommandé d’appeler trigger et de définir element sur le nœud DOM de la bannière principale.

trigger({
  element: element // the value would be the DOM node
});

Respect de l’ordre des règles

Platform Launch permet aux utilisateurs d’ordonner des règles. Par exemple, un utilisateur peut créer deux règles qui utilisent toutes les deux le type d’événement de changement d’orientation. Il souhaite aussi personnaliser l’ordre dans lequel les règles se déclenchent. Supposons que l’utilisateur de Platform Launch spécifie une valeur d’ordre de 2 pour l’événement de changement d’orientation dans la règle A et une valeur d’ordre de 1 pour l’événement de changement d’orientation dans la règle B. Ces valeurs indiquent que lorsque l’orientation change sur un équipement mobile, la règle B doit se déclencher avant la règle A (les règles avec les plus petites valeurs d’ordre se déclenchent en premier).

Comme mentionné précédemment, la fonction exportée dans notre module d’événement sera appelée une fois pour chaque règle configurée pour utiliser notre type d’événement. Chaque fois que la fonction exportée est appelée, elle transmet une fonction trigger unique liée à une règle spécifique. Dans le scénario qui vient d’être décrit, notre fonction exportée sera appelée une fois avec une fonction trigger liée à la règle B, puis une autre fois avec une fonction trigger liée à la règle A. La règle B est appelée en premier parce que l’utilisateur lui a donné une valeur d’ordre inférieure à la règle A. Lorsque notre module de bibliothèque détecte un changement d’orientation, il est important d’appeler les fonctions trigger dans l’ordre dans lequel elles ont été fournies au module de bibliothèque.

Dans l’exemple de code ci-dessous, notez que lorsqu’un changement d’orientation est détecté, les fonctions de déclenchement sont appelées dans l’ordre selon lequel elles ont été fournies à notre fonction exportée :

var triggers = [];

window.addEventListener('orientationchange', function() {
  triggers.forEach(function(trigger) {
    trigger();
  });
});

module.exports = function(settings, trigger) {
  triggers.push(trigger);
};

Cela permet de s’assurer que l’ordre spécifié par l’utilisateur est conservé.

Une implémentation incorrecte serait celle qui appelle les fonctions de déclenchement dans un ordre différent :

var triggers = [];

window.addEventListener('orientationchange', function() {
  for (var i = triggers.length - 1; i >= 0; i--) {
    triggers[i]();
  }
});

module.exports = function(settings, trigger) {
  triggers.push(trigger);
};

Les pratiques de programmation naturelle maintiennent généralement l’ordre adéquat, mais il est important de connaître les implications et de les développer en conséquence.

Sur cette page