Javascript : ce que vous devez savoir pour le tag management

Ici, chez Webalab EMEA Consulting, nous sommes, fondamentalement, ce qu’on pourrait appeler des mauvais développeurs, mais enthousiastes. Des maudevastes (le brevet est déposé, cherchez pas). Nous sortons tous les 3 de formations non techniques (quadruple cursus webmarketing / commerce / disruption / arts du spectacle en ce qui me concerne) où la chose la plus technique était sans doute le cours de bureautique de 1ère année sur Microsoft Excel 2007. J’en deviendrais presque nostalgique.

Ce qui nous amène à notre sujet : lorsque l’on travaille régulièrement sur des outils de type Tag Management System (TMS), en particulier notre marotte Google Tag Manager, faut-il avoir des connaissances en Javascript ? Ça n’engage que moi, mais je pense qu’il n’y a même pas de débat. Oui, pour utiliser un TMS, il faut un minimum connaître JS. Le vrai débat est « simplement » de savoir jusqu’à quel niveau aller.

En effet, JS est un langage de plus en plus difficile à appréhender aujourd’hui : à l’origine codé en deux semaines par un développeur ivre enthousiaste mais qui n’avait pas moindre idée de l’ampleur que ça allait prendre, le JS est aujourd’hui devenu nettement plus structuré, et donc, fatalement, un chouïa moins accessible au commun des mortels (nous, donc) qu’il y a encore 6 ou 7 ans. De nos jours, tout dev JS qui se respecte se doit de connaître React, Node, Webpack, Babel, ESLint, TypeScript, voire Jquery s’il travaille pour un institut bancaire depuis son Packard Bell Edition Premium Windows XP (auquel cas il a quand même 14 semaines de congés payés, il faut savoir relativiser).

Mais après tout, pourquoi se parler de JS, alors que GTM lui-même est un outil dont l’objectif est justement d’abstraire cette complexité, pour vous permettre de manipuler ce qui rentre / sort de notre cher data layer, sans avoir à mettre les mains dans le code ?

Premièrement, avoir une compréhension générale des grands principes de JS reste un gros atout pour mieux appréhender ce qui se passe dans « le moteur » de GTM (par exemple, les lookups table ne sont qu’un switch…case avec une interface graphique). Mais aussi, et surtout, GTM a souvent des limites dans ce que l’on peut faire dans la partie « no code ». Parfois, quelque chose qui pourrait être une véritable usine à gaz côté variables et tags « templatisés », ou bien impliquerait un nouveau dev, une nouvelle recette, mise en prod et tutti quanti, peut se régler avec moins de 5 lignes de JS bien fagoté.

Petit aparté : depuis quelques années, on parle beaucoup sur les Internets d’outils de « no code », qui permettent souvent de faire des miracles (bases de données, design, déploiement…) sans faire une seule ligne de JS, Python, CSS, ou autre. GTM, dans cette optique, serait beaucoup plus proche d’un outil qu’on pourrait qualifier de « light code », dans le sens où on peut largement s’abstraire de JS, mais où, lorsqu’on doit tout de même en faire, il est relativement cadré, et ne nous oblige pas à réinventer la roue.

Disclaimer : ceci n’est pas un tuto complet sur JS, et ne remplacera jamais un bon petit MOOC, où vous irez beaucoup plus dans le détail, en expérimentant. L’idée est plus de revenir sur les concepts de base, pour chaque partie, et de vous donner envie, si besoin, d’aller plus loin, en vous fournissant les liens vers la partie la plus appropriée des internets.

Préambule : HTML et CSS

Avant d’attaquer JS à proprement parler, il faut bien entendu avoir quelques bases en HTML et CSS. Rien de bien méchant, mais côté HTML il faut au moins connaître les principales balises, ainsi que leur signification sémantique : p, ul, ol, li, img, div, span, bref, si jamais vous avez besoin d’un petit reminder allez faire un petit tour sur la doc.

Tout ce qui touche à la meta de la page (meta description, title, meta OG, canonical) peut aussi être intéressant à avoir en tête, notamment si vous venez du SEO, mais pas que.

Pour ce qui est du CSS, il est surtout important de comprendre le concept de sélecteur : par une classe, un ID, un sélecteur descendant, combiné… Il est crucial de savoir les reconnaître, et même de jouer un minimum avec.

p{
	/* Sélection de toutes les balises paragraphe */
}

#final_paragraph{
	/* Sélection de la balise d'ID final_paragraph" */
}

.blue_paragraph{
	/* Sélection de toutes les balises de classe "blue_paragraph" */
}

.blue_paragraph span {
	/* Sélection de toutes les balises "span" descendantes de la classe "blue_paragrap" */
}

Petite astuce au passage : si vous êtes sur une page quelconque et que vous voulez, pour une balise donnée, récupérer un sélecteur CSS qui va bien, vous pouvez faire un clic droit puis « Inspecter » sur l’élément, et, ensuite, dans le menu « Éléments » du débugueur, faire un clic droit sur la balise qui vous intéresse et faire Copy => Copy selector :

Cela vous donnera quelque chose comme body > div.siteContainer.siteBody > main > section.main_container > section.colonne > section.verticalListing > ul > li:nth-child(20) > article > a > div > h2. Le point n’est pas de comprendre dans le détail comment est construit ce sélecteur, mais peut servir pour cibler certains éléments dans GTM. On en reparle un peu plus tard #suspense.

Pour ce qui est des règles CSS à proprement parler (positionnement, couleurs, bordures, typo…) qui vont venir se garer à l’intérieur desdits sélecteurs, il n’y a pas grand-chose qui nous intéresse réellement, on va laisser les vrais front devs faire leur boulot.

Allez, l’échauffement est terminé, on va passer à la partie sur le JS à proprement parler.

Variables : déclaration et manipulations

Commençons par le commencement : déclarer une variable. JS est un langage dit à « typage laxiste » (contrairement, par exemple, à Java), à savoir que vous n’allez pas préalablement déclarer un type string, integer, float, etc.

var myBoolean = true;
var myInteger = 27;
var myFloat = 32.4;
var myString = 'hello World';

On n’oublie pas 2 notions fondamentales : toute instruction JS se finit par un point virgule, et on peut utiliser au choix des simples ( ‘ ) ou double quotes (  » ) autour des strings dans son code, l’important étant d’être consistant.

En JS, on écrit les noms de variable en camelCase : on met les mots à la suite, dans espace, avec une première lettre en minuscule.

Soyez consistants, bordel, je n’en peux plus de récupérer des containers GTM qui utilisent un mélange de camelCase, du snake_case, et de TrUcS_-BiZarresK🅰se. Ça n’a l’air de rien, mais rien qu’une bonne consistance entre vos noms de variables fait gagner en lisibilité. Merci de votre mansuétude.

Les arrays et les objets

Nous avons fait le tour des types dits « primitifs », mais on se rend compte que dès lors qu’il s’agit de jouer avec de la donnée un minimum structurée, de simples strings ne suffisent pas. Nous avons donc à dispo les arrays (tableaux) dénotés par d’élégants crochets :

var myArray = ['product1','product3','product546'];

Il faut bien entendu connaître les principales méthodes permettant de requêter / modifier un élément particulier dans un array…

myArray[1]; //renvoie 'product3'
myArray[2] = 'newproduct' ; //modifie le 3ème élément de l'array

…ou encore d’ajouter / retirer, et donc altérer un array. La méthode la plus connue des gars sûrs de la webanalytics est bien entendu le .push, qui ajoute un élément à la fin du tableau, mais il en existe tout un tas : pop, shift, unshift… Gardez toujours ce lien dans un coin de vos bookmarks, ça peut servir.

Il est crucial de comprendre que dans un array, on peut stocker n’importe quoi (strings, integers, et tous leurs copains sus-mentionnés), mais qu’en règle générale, on va se servir de ce type de variable pour stocker des informations de même type (ici, des noms de produits).

Petite astuce : si on veut savoir si une variable est un array, « typeof » ne fonctionne pas, il faut utiliser Array.isArray(nomDeMaVariable).

var myArray = ['aa','bbb'];
typeof myArray; //renvoie "Object", ça nous fait une belle jambe
Array.isArray(myArray); //renvoie true, c'est déjà plus smooth

Lorsqu’on veut, en revanche, stocker de la donnée d’une façon un peu plus structurée, il va falloir faire appel à des objets. Un objet est tout simplement une variable qui contient un ensemble de clés / valeurs, à l’intérieur d’accolades :

var user = {
	'firstName' : 'Michel',
	'lastName' : 'Dupont',
	'age' : 30,
	'isClient' : false
};

Du côté de la manipulation des objets, le principe est le même qu’avec un array, avec cette fois une écriture sous la forme objet.clé ou encore objet[clé] (c’est équivalent) :

user.firstName; //renvoie 'Michel'
user.lastName = 'Dubois'; //modifie la valeur de la clé lastName à la volée
user.country = 'Spain'; //ajoute une clé 'country' avec une valeur 'Spain'

Il faut bien comprendre que, dans un objet, il n’y a pas de notion d’ordre. Cela peut sembler un peu déroutant lorsqu’on a plus l’habitude des arrays, mais n’allez pas essayer de récupérer le 3ème élément d’un objet, c’est conceptuellement impossible. On y reviendra dans les boucles.

À noter qu’il est tout à fait possible, et même courant, de faire un array d’objets :

var products = [
{
'id' : 432342,
'name' : 'Baskets Nike',
'size' : 43,
'price' : 132
},
{
'id' : 88643,
'name' : 'iPhone 22',
'size' : 512,
'price' : 4000
},
]

Ici on a donc un array « products », qui contient lui-même deux objets contenant chacun les infos d’un produit donné.

Eh oui, ceux qui connaissent déjà bien GTM savent évidement que c’est précisément le cas de notre très cher data layer.

La boucle if / else, switch, ternaires

Maintenant qu’on sait déclarer et manipuler les variables classiques en JS, et récupérer des éléments unitairement à l’intérieur des arrays et objets, passons aux boucles. La plus simple est ce bon vieux if…else if…else :

var myNumber = 17;

if(myNumber > 12){
	console.log('Nombre supérieur à 12');
}
else{
	console.log('Nombre inférieur ou égal à 12');
}

Rien de bien foufou, si ce n’est un léger point sur lequel je me permets d’insister : une instruction présente à l’intérieur d’une paire d’accolades n’est exécutée que si la condition dans le « if », « else if » ou « else » est évaluée à true. Dans le cas ci-dessus, il paraît assez intuitif qu’il est « vrai » que la valeur de ma variable est supérieure à 12 (Bac + 5, merci). Si on regarde un peu plus loin sous le capot, en réalité, JS convertit ce qu’il y a entre les parenthèses en un booléen (true ou false, donc).

Ah oui, au passage, un petit mot sur les console.log : si jamais vous ne connaissez pas cette technique, il s’agit tout simplement d’afficher le résultat d’une opération quelconque ou encore d’une variable dans la console du debug de votre navigateur préféré (Sauf sur TagCo. Mais c’est une histoire pour un autre jour) :

En fait, ce détour est un prétexte pour vous enjoindre de ne jamais laisser de console.log en prod. Jamais. Ne faites pas ça. Historiquement, la raison est que cela faisait planter des vieilles versions d’Internet Explorer (petit ange parti trop tôt) ; aujourd’hui, ce n’est plus le cas, mais, je vous en prie, respectez-vous, vous valez mieux qu’une régie publicitaire, où je pense sincèrement qu’il existe un poste de « Head of console log en prod » (je vais chercher sur LinkedIn, tiens).

Complexifier la boucle if avec des opérateurs

À l’intérieur de nos conditions if & cie, on peut bien évidemment complexifier la chose et cumuler des conditions avec les opérateurs && (« et »), et || (« ou ») :

var myNumber = 17;
var myOtherNumber = 12;

if(myNumber > 12 && myOtherNumber > 12){
	console.log('Mes deux nombres sont supérieurs à 12');
}

if(myNumber > 15 || myOtherNumber > 15){
	console.log('Au moins un des deux nombres est supérieur à 15');
}

Il est très courant de cumuler des conditions de la sorte, et il est bien sûr, dans la limite de la lisibilité, d’ajouter plusieurs opérateurs à la suite (condition1 && condition2 && condition3…).

Terminons sur une boucle if simplifiée, le ternaire :

var myNumber = 17;
var control = 0;

if(myNumber > 12){
	control = 1;
}
else{
	control = 2;
}
//Un peu long à écrire, non?

myNumber > 12 ? control = 1 : control = 2;
//Ecriture équivalente avec un ternaire

Lorsqu’un peut remplacer un if…else par un ternaire, autant ne pas se priver, encore une fois dans la mesure où la ligne ne fait pas 14 Km de long. Il est surtout important de la connaître si jamais on tombe dessus dans un code que l’on découvre, la notation en elle-même étant un peu cryptique lorsqu’un la découvre pour la 1ère fois.

Tester l’égalité entre 2 variables

Tester si deux variables sont égales (typiquement, dans une condition if comme ci-dessus) va se faire à l’aide de l’opérateur ==, ou encore === :

var firstNumber = 17;
var otherNumber = '17';

laxistTest = firstNumber == otherNumber; //renvoie true
laxistTest = firstNumber === otherNumber; //renvoie false

Là, on rentre vraiment dans le côté cordial de JS (ou alors qu’on s’arrache les cheveux, ça dépend des points de vue ou du nombre de cafés ingérés). En gros, la triple égalité va tester que les 2 variables sont de même valeur et de même type (jusqu’ici tout va bien), tandis que la double égalité va « juste » tester la valeur, c’est-à-dire convertir à la volée les variables (dans le cas ci-dessus, un integer 17 en string « 17 »). Si vous avez envie d’en savoir plus, je vous invite à regarder ce que les devs JS appellent intimement « le tableau de conversion de l’enfer » pour comprendre comment réagit vraiment la double égalité :

Si vous n’avez qu’une chose à retenir, c’est d’utiliser au maximum possible la triple égalité. Alors oui, certains devs expérimentés utilisent l’égalité « laxiste » à leur avantage, mais pour nous autres, pauvres mortels, cela risque plutôt de nous jouer des tours. Donc on ne discute pas, et on fait autant que possible de l’égalité stricte, et que ça saute.

La boucle for, et les améliorations

La boucle for va nous permettre d’itérer sur des arrays pour faire des trucs sur chacun des éléments de l’array :

var myArray = ['riri','fifi','loulou'];

for (var i = 0; i < myArray.length; i++) {
	console.log(myArray[i]);
}

La boucle for est le grand classique qui vous permet de faire à peu près n’importe quoi. Alors oui, les puristes du JS vous diront qu’il existe environ 50 types de boucle plus spécifiques, nettement plus performances et surtout élégantes que for : reduce, filter, map… Honnêtement, ne complexez pas : une boucle for fera toujours le job, sera compréhensible par tous, et restera lisible à condition de ne pas les chaîner comme un cochon. Lorsque vous serez à l’aise avec « for », allez donc jeter un oeil aux méthodes d’itération avancées des arrays.

Et si je veux parser un objet?

Reprenons un objet de type produit :

var product = {
	'id' : 432342,
	'name' : 'Baskets Nike',
	'size' : 43,
	'price' : 132
}

Ne vous amusez pas à faire un « for » là-dessus, vous allez juste mettre votre navigateur en PLS (c’est faux, en réalité il ne se passera juste pas grand-chose, il se moquera juste de vous silencieusement). Alors techniquement, si on veut parser un objet, il s’agit d’une boucle for, mais avec une syntaxe un peu différente :

for (var item in product){
	console.log(item);
	console.log(products[item]);
}

À noter qu’au même titre que « i » dans une boucle for, « item » est ici notre variable de boucle ; libre à vous de l’appeler comme vous le sentez.

Les éléments de la page qu’il faut connaître

Pour l’instant, toute notre petite affaire manque un peu de concret, et à part déclarer des variables bidon, et faire des console.log, rien qui ressemble au Vrai Internet. Et chez Webalab Consulting, nous sommes convaincus que le Vrai Internet est celui qui saura accompagner votre transformation digitale (sont pénibles les Sales à avoir la main sur le BO WordPress).

Commençons simplement par cette bonne vieille URL. Un objet « document.location » est accessible en JS, et comporte des sous-objets permettant de récupérer des portions de l’URL :

Par exemple, « document.location.pathname » permet de récupérer l’URI (l’URL sans le nom de domaine), que l’on envoie traditionnellement à Google Analytics et consorts.

Au passage, petit hijack pour vous parler rapidement de la méthode « split », qui, appliquée comme ceci, transformera une string en array en utilisant un séparateur que vous spécifierez bien tranquillement :

Alors bien sûr, GTM permet de récupérer ceci de façon simple, mais cela reste toujours intéressant de connaître la technique pour faire des variables « composites » (ex : une URL complète contenant le hash dans un paramètre custom)

Un autre exemple d’élément que vous pouvez récupérer dans la page est, ben…bah…le contenu de la page, en fait (sans déconner ?). Vous vous souvenez de nos bons vieux sélecteurs CSS du début de l’article ? Eh bien nous allons utiliser exactement la même chose dans JS :

var mySelector = document.querySelector('#content > article');

On balance donc à manger n’importe quel sélecteur CSS entre quotes à notre « querySelector », et il nous retourne un objet bien touffu, avec lequel en soi, bah, on ne peut pas faire grand-chose :

En soi, nous allons pouvoir exploiter ceci via un mySelector.outerHTML(ou toute autre propriété de la div) ou encore un mySelector.textContent, qui vous donnera le contenu textuel de la div.

À noter qu’on peut aussi utiliser un document.querySelectorAll : même principe, mais cette fois, JS nous retourne un array qui contient toutes les divs répondant au sélecteur, qu’on peut, comme d’habitude, passer dans une moulinette « for » pour remonter, par exemple, tous les IDs de produit d’une page donnée.

Les plus filous d’entre vous sont déjà en train de se dire « hé mais mec, tu es clairement en train de nous dire de faire du DOM scrapping dans GTM ! Tu n’avais pas dit que le DOM scrapping dans GTM, c’était un peu de la m… ? ». Alors, oui, certes. Mais bon, il reste important de connaître le concept, et oui, on reparlera de DOM scrapping un jour. Quand j’aurai dormi.

Les fonctions

Tout développeur vous le dira : le principe numéro 1 d’un code de qualité est DRY : Don’t Repeat Yourself. Dès que, dans un script donné, on doit répéter une même tâche assez semblable plus d’une fois, il faut se poser la question de créer une fonction, un bloc de code réutilisable :

function logStuffToConsole() {
	console.log('Votez Webalab en 2022!');
}

//La fonction en elle-même est, pour l'heure, juste déclarée, mais pas appelée

logStuffToConsole();
//On appelle ensuite la fonction pour afficher le message dans la console

Évidemment, une fonction peur aller prendre des arguments, que l’on va mettre dans nos petites parenthèses :

function logStuffToConsole(candidate) {
	console.log('Votez ' + candidate + ' en 2022!');
}

logStuffToConsole('Karim Benzema');

Enfin, une fonction peut ‘retourner’ une valeur : cela va permettre de créer une variable dont la valeur correspondra au callback de la fonction :

function multiplyBy42(userNumber) {
	return userNumber*42;
}

var myMultipliedNumber = multiplyBy42(24);
//Devrait retourner 1008 si tout se passe bien

Note syntaxique : on parle aussi de méthode pour désigner une fonction en JS. C’est la même chose, ne soyez pas surpris si vous voyez ce terme apparaître dans la littérature (Marcel Proust, Guy de Maupassant, Squeezie…).

Autant ce concept est fondamental en JS, autant dans GTM, il sera plutôt rare de l’utiliser : eh ben oui, nous avons les variables (au sens GTM du terme hein, anciennement les « macros ») qui fonctionnent complètement selon cette logique (bah ouais, function…return, tout ça tout ça).

Manipuler les dates

Évidemment, impossible de ne pas aborder la manipulation de date, classique parmi les classiques. Comme tout langage qui se respecte, on peut récupérer le timestamp courant (le nombre de secondes écoulées depuis le 1er janvier 1970) de la sorte :

Date.now()

C’est le moment où vous pouvez faire une blague super gênante du genre « Hé Bernard, tu passes me chercher demain à 1616251490 ? » (perso, moi ça me fait rire)

Bien sûr, libre à vous de faire ensuite plein de calculs choupichous et autres joyeusetés grâce à ce magnifique timestamp (par exemple, pour calculer la différence entre le timestamp courant et une date de publication d’un contenu déversé dans votre beau data layer, mais je dis ça je dis rien).

Vous pouvez également faire un « new Date », qui retourne cette fois une date « formatée » :

L’intérêt est que si vous venez rentrer ce « new Date » dans une variable, vous pouvez utiliser tout un tas de méthodes permettant de récupérer certaines informations sur la date, par exemple, si on veut créer un format « lisible » du type AA/MM/JJ

var myDate = new Date;

console.log(myDate.getDate()); //Renvoie le jour du mois, entre 1 et 31
console.log(myDate.getDay()); //Renvoie le jour de la semaine, par exemple 6 pour un samedi
console.log(myDate.getYear()); //Renvoie l'année. Incroyable, non?

Et afin de boucler la boucle, voyons comment convertir un timestamp en date :

var unixTimestamp = 1549312452;
var date = new Date(unixTimestamp * 1000);

Oui, c’est d’une simplicité désarmante, je sais. J’aurais souhaité que ça soit plus compliqué et j’ai fait mon maximum, désolé. Ne vous inquiétez pas, on parlera d’Adobe Analytics bientôt.

Cookies et local storage

On ne va pas se mentir, créer un cookie est une grosse tannée en JS :

document.cookie = "username=Michel Michel; expires=Thu, 18 Dec 2022 12:00:00 UTC; path=/";

La douille est que la valeur de notre document.cookie doit être une string parfaitement formatée, avec, donc, sa valeur (ici, « username ») sa date d’expiration et son path (ce qui permet de poser un cookie au niveau du top level domain, typiquement).

Dès que vous allez créer un cookie avec une logique un peu complexe, il faudra donc en général faire les calculs séparément, puis concaténer tout ceci dans une belle string qui servira donc à créer notre cookie.

Maintenant, qu’en est-il de la lecture d’un cookie en particulier ? Eh ben dans le genre grosse tannée, une fois encore ça se pose là, puisque les cookies sont disponibles dans une variable JS « document.cookie », qui est une grosse string globale qui reprend l’intégralité des cookies posés sur un site donné :

L’idée, pour récupérer un cookie en particulier, est bien sûr de transformer cette string en un array en bonne et due forme (split, si vous vous souvenez), puis de récupérer la valeur d’un cookie en particulier. Pour cette fois-ci, je vous épargne l’exemple, car GTM nous permet totalement d’abstraire cette logique et de récupérer la valeur d’un cookie via une simple variable. Parfois, il peut être simplement utile de rendre hommage à toutes ces heures que GTM nous fait gagner, dans sa grande mansuétude.

Parlons maintenant du local storage. Celui-ci a justement été créé comme une alternative plus moderne et flexible aux cookies. Regardons simplement comment cela se comporte :

localStorage.setItem('userId', '123456');
//Créer une entrée de local storage

var cat = localStorage.getItem('userId');
//Récupérer une entrée de local storage

localStorage.removeItem('userId');
//Supprimer une entrée de local storage

Eh oui, je pense que cela se passe d’explication, le code se suffit à lui-même : une fois que vous avez lu ces 3 malheureuses lignes de code, vous avez tout compris au local storage.

À noter que le session storage fonctionne exactement de la même façon, mais que comme son nom l’indique, il est automatiquement supprimé dès que l’utilisateur ferme son navigateur pour aller jouer à Animal Crossing.

Events listeners

Les events listeners sont à peu de chose près l’élément le plus important du « vrai » dev front, dans le sens où c’est le fondement permettant d’animer la page sur la base des interactions utilisateur (oui, il est revenu de sa session Animal Crossing).

Regardons un peu de quoi il en retourne. La syntaxe peut paraître un peu étrange pour les non initiés, mais une fois que vous aurez compris la structure, ça rentrera tout seul (c’est comme le vélo, ou encore la pose d’un bel enduit de finition sur du placo en BA-13, mais je m’égare) :

function headerClick(){
	console.log('Click on header');
}
//On commence par déclarer la fonction qui sera appelée lors de l'action utilisateur, mais pour l'instant, elle n'est pas appelée
 
var headerSelector = document.querySelector('#header > div > .');
//On met notre sélecteur dans une variable

headerSelector.addEventListener('click',headerClick);
//On "attache" notre fonction "headerClick" à l'action de clic sur l'élément concerné par notre sélecteur CSS

Notre « click » présent dans l’event listener peut tout à fait être remplacé par toute une palanquée d’interactions : click, mousein (la souris entre sur l’élément), mouseout, onfocus…

Il faut bien comprendre la notion de « découplage » de la fonction, du sélecteur, et du listener à proprement parler, puisque l’idée est justement d’avoir du code réutilisable : un même élément peut avoir un comportement différent au clic ou au focus, par exemple.

L’avantage, c’est que GTM, via ses triggers, gère une grande partie ceci nativement (notamment pour les clics), mais si jamais vous devez mettre un listener un peu touffu (un focusout sur un champ de formulaire, typiquement), il faut typiquement faire ce genre de chose.

Un mot sur ES6

ES6, c’est quoi ? Pour vulgariser un peu, ES (EcmaScript) est la version de Javascript, qui a comme tout un chacun (sauf l’interface admin de GA), évolué. ES5, ES6… Pour vous donner une idée, la dernière version, à l’heure où j’écris cet article, est ES12. Pourquoi est ce que je vous bassine avec ça? Eh bien, parce que GTM, de base, est resté bloqué à ES5 (ES6 date de 2015, je dis ça je dis rien). Et ES6 a été une grosse avancée, en JS, question syntaxe.

En soi, ça ne va pas nous changer la vie : dans GTM, nous faisons rarement des choses où l’emploi d’ES6 et + apporterait une valeur ajoutée conséquente. Cela dit, là où la situation se complique, c’est que, de plus en plus, lorsqu’on cherche de la doc où de l’aide sur les internets, on tombe sur des exemples en ES6, qu’il faut savoir traduire en ES5 pour les donner à manger à GTM.

Si vous devez connaître quelques concepts d’ES6, les voici, avec leur traduction en ES5 :

const userID = 321654; 
let transactionAmount = 24;
//En ES6, on déclare spéciquement des constantes, variables qui ne sont pas amenées à changer, alors que "let" permet d'avoir une variable plus flexible 

var userID = 321654; 
var transactionAmount = 24;
//En ES5 on ne fait pas ce distinguo



myFunction = argument => {
	// On fait des trucs dans le corps de notre fonction, avec la syntaxe "arrow function"
}

function myFunction(argument) {
	// On fait des trucs dans le corps de notre fonction, mais en ES5
}



const outsideTextES6 = 'inside text';
const myConcatES6 = `some text ${outsideTextES6} some other text`;
//Notez l'utilisation des "backticks" dans notre concaténation, qui permet d'appeler nos variables sans "fermer"

var outsideTextES5 = 'inside text';
var myConcatES5 = 'some text' + outsideTextES5 + 'some other text';

Je vous conseille également de jeter un œil à ce repo si vous ne connaissez pas (encore) ES6, mais que vous avez envie d’en savoir un peu plus sur les features sympa que cela apporte par rapport à ES5.

Alors oui, mille fois oui, en tant que développeur full stack avec plus de 10 ans d’expérience en création d’architectures at scale*, cela me fend le cœur de toujours devoir utiliser cette syntaxe préhistorique, et que GTM soit encore bloqué à une version de JS qui a 6 ans de retard. Certes, il est possible d’utiliser ES6 dans les merveilleux templates de GTM (dont je parlerai, un jour, promis), et le concept est prometteur, mais au moment où j’écris ces lignes, de nombreuses choses ne peuvent pas êtres faites via le JS « surchargé » (dans l’absolu, je dirais plutôt « sous chargé », mais pas sûr que ça soit très français) des templates que je trouve pour l’instant trop peu permissif.

*C’est faux, je passe juste 90% de mon temps à copier coller salement des snippets de StackOverflow, et j’ai fait 2 3 tutos histoire de paraître sérieux

Les notions utiles en JS, mais pas pour GTM

Petit tour rapide de quelques notions qui apparaîtraient dans tout bon tuto JS qui se respecte, mais qui, dans l’optique de devenir un ninja de GTM, ne vous seront pas d’une grande utilité :

  • Insérer des éléments à la volée dans le DOM
  • Récupérer des données en mode asynchrone via une API quelconque

Bilan

Au risque de me répéter, ce rapide-mais-pas-tant-que-ça guide n’a pas vocation à être exhaustif pour ce qui est des connaissances que vous devez avoir pour utiliser confortablement du JS dans GTM. Il s’agit plutôt d’une trame pour vous partager quelques astuces vraiment utiles pour le Tag Management, et vous inciter à aller plus loin si vous voulez creuser le sujet.

Si jamais vous êtes un vrai développeur (je ne sais pas trop comment vous êtes arrivé jusqu’ici, vous devriez avoir mieux à faire, sincèrement), je m’excuse platement pour toutes les approximations et autres abominations qui pourraient être présentes dans mes snippets JS. Bien évidemment, je suis clairement preneur de toute suggestion pour améliorer ceci.

Si l’article vous a plu, n’hésitez pas à le partager à tous vos amis, à votre maman, à votre chien, et à nous suivre sur les réseaux sociaux pour toujours plus de friandises liées à l’analytics.

Cœur sur vous dans le respect des gestes barrières ♥

Hello 👋 Merci d'avoir lu !

On vous invite à ne manquer aucun article en vous inscrivant !

Nous ne spammons pas ! Consultez notre politique de confidentialité pour plus d’informations.