Comprendre le contexte d’exécution de HTML this form en JavaScript

En JavaScript, le mot-clé this ne désigne pas toujours le même objet. Sa valeur dépend du contexte dans lequel une fonction est appelée. Quand un formulaire HTML déclenche du code JavaScript, via un attribut inline ou un écouteur d’événement, la référence de this change selon la méthode de liaison utilisée. Comprendre ce mécanisme évite des bugs courants lors de la validation ou de l’envoi de données de formulaire.

Attribut inline et valeur de this dans un formulaire HTML

Le cas le plus ancien, encore répandu dans du code existant, consiste à écrire un gestionnaire directement dans le HTML. Un attribut comme onsubmit placé sur la balise <form> crée un contexte d’exécution particulier.

A lire aussi : Conception UX et UI : comprendre ce qui distingue vraiment les deux

Dans cette configuration, le navigateur génère une fonction enveloppante dont le this pointe vers l’élément DOM qui porte l’attribut, c’est-à-dire le formulaire lui-même. Écrire <form onsubmit="console.log(this)"> affiche dans la console l’objet HTMLFormElement correspondant.

Ce comportement permet d’accéder directement aux champs du formulaire via this.elements ou this.action sans passer par document.getElementById. La spécification WHATWG (section « Event handlers ») décrit précisément ce mécanisme : le code de l’attribut est inséré dans un corps de fonction dont le this est lié à l’élément cible de l’événement.

A lire également : Internet et web : enfin comprendre ce qui les distingue vraiment

La spécification WHATWG considère toutefois cette approche comme une solution de compatibilité plutôt qu’une bonne pratique. La recommandation actuelle privilégie la liaison des événements en JavaScript séparé, ce qui modifie la manière dont this se comporte.

addEventListener et fonction classique : this lié au formulaire

Quand le code JavaScript est séparé du HTML, la méthode addEventListener remplace l’attribut inline. Avec une fonction classique (function), le comportement de this reste cohérent avec le cas précédent.

Voici le mécanisme concret :

• document.querySelector('form').addEventListener('submit', function(event) { ... }) crée un écouteur où this référence l’élément sur lequel l’écouteur est attaché, donc le formulaire.
• À l’intérieur du callback, this.elements donne accès à la collection des champs, this.method renvoie GET ou POST, et this.action renvoie l’URL cible.
• L’objet event passé en paramètre contient aussi event.target, qui pointe vers le même formulaire dans ce scénario. Les deux sont interchangeables ici, mais pas dans tous les cas (événements délégués, par exemple).

Cette approche sépare le comportement du balisage. Le formulaire HTML ne contient plus de JavaScript, et le script peut être chargé en fin de page ou via un attribut defer.

Fonction fléchée dans addEventListener : this ne pointe plus sur le formulaire

Le piège le plus fréquent concerne les fonctions fléchées (arrow functions). Elles ne possèdent pas leur propre liaison de this. Elles héritent du this du contexte lexical englobant, c’est-à-dire la portée dans laquelle elles ont été définies.

En pratique, si le script s’exécute au niveau global d’un fichier classique (<script> sans attribut type="module"), this dans la fonction fléchée vaut window. Si le mode strict est actif, il vaut undefined.

Écrire form.addEventListener('submit', (event) => { console.log(this); }) n’affiche donc pas le formulaire. this dans une fonction fléchée ignore complètement l’élément DOM. Pour accéder au formulaire, il faut utiliser event.target ou event.currentTarget à la place.

Ce changement de comportement casse les exemples historiques qui utilisaient this dans des callbacks d’événements. Migrer un gestionnaire inline vers un addEventListener avec fonction fléchée sans adapter les références à this produit des erreurs silencieuses : le code s’exécute, mais this.elements renvoie undefined puisque window n’a pas de propriété elements.

Script type= »module » et contexte global de this en JavaScript

Le contexte d’exécution change encore lorsque le code est chargé avec <script type="module">. Dans un module, this au niveau supérieur vaut undefined, pas window.

Ce comportement a une conséquence directe sur le code qui manipule des formulaires. Du code écrit au niveau global d’un module, en dehors de toute fonction, ne peut pas utiliser this pour référencer quoi que ce soit. Même une fonction classique définie au niveau du module et appelée directement (pas comme callback d’événement) aura un this à undefined en mode strict.

En revanche, un callback classique passé à addEventListener depuis un module fonctionne normalement : this pointera toujours sur l’élément DOM, car c’est le moteur d’événements du navigateur qui fixe la valeur de this au moment de l’appel. La règle du module n’affecte que le this de portée supérieure, pas celui injecté par l’API DOM.

Choisir la bonne approche pour accéder à un formulaire en JavaScript

Trois situations coexistent dans les projets actuels. Le choix dépend du contexte technique et de la base de code existante.

• Le gestionnaire inline (onsubmit="...") fonctionne avec this pointant sur le formulaire, mais il mélange HTML et JavaScript. Il reste adapté à du prototypage rapide ou à du code legacy.
• La fonction classique dans addEventListener offre un this fiable lié au formulaire, tout en séparant le script du balisage. C’est la méthode la plus prévisible pour manipuler this dans un contexte d’événement.
• La fonction fléchée dans addEventListener est préférable quand le code utilise déjà des closures ou des classes, à condition de remplacer systématiquement this par event.target ou event.currentTarget pour accéder au formulaire.

Le paramètre event passé au callback reste la méthode la plus sûre quelle que soit la syntaxe. event.target fonctionne partout, indépendamment du type de fonction ou du mode d’exécution du script. Partir de cette référence plutôt que de this rend le code portable entre scripts classiques, modules et frameworks.

La valeur de this dans un formulaire HTML dépend donc de trois facteurs combinés : le type de liaison (inline, addEventListener), le type de fonction (classique, fléchée) et le mode d’exécution du script (classique, module, strict). Garder ces trois axes en tête permet de diagnostiquer rapidement un this qui ne pointe pas là où on l’attend.