Quelles sont les règles de gestion des événements dans le développement web ?

Cette fois, je vais vous expliquer quelles sont les règles de gestion des événements dans le développement Web, et quelles sont les précautions pour la gestion des événements dans le développement Web. Ce qui suit est un cas pratique. Jetons un coup d'oeil.

Traitement des événements

Nous savons que lorsqu'un événement est déclenché, l'événement objet (objet événement) sera transmis au gestionnaire d'événements en tant que paramètre de rappel par exemple. :

// 不好的写法function handleClick(event) {  var pop = 
document
.getElementById('popup');
  popup.style.left = event.clientX + 'px';
  popup.style.top = event.clientY + 'px';
  popup.className = 'reveal';
}// 你应该明白addListener函数的意思addListener(element, 'click', handleClick);

Ce code n'utilise que deux attributs de l'objet événement : clientX et clientY. Utilisez ces deux attributs pour positionner l'élément avant de l'afficher sur la page. Bien que ce code semble très simple et ne pose aucun problème, c’est en fait une mauvaise façon de l’écrire car cette approche a ses limites.

Règle 1 : Isoler la logique de l'application

Le premier problème avec l'exemple de code ci-dessus est que le gestionnaire d'événements contient une logique d'application. La logique de l'application est un code fonctionnel lié à l'application, et non au comportement de l'utilisateur. La logique d'application dans l'exemple de code ci-dessus consiste à afficher une boîte de dialogue contextuelle à un emplacement spécifique. Bien que cette interaction doive se produire lorsque l’utilisateur clique sur un élément spécifique, ce n’est pas toujours le cas.

C'est une bonne pratique de séparer la logique d'application de tous les gestionnaires d'événements, car on ne sait jamais quand la même logique sera déclenchée ailleurs. Par exemple, vous devez parfois déterminer s'il faut afficher une boîte de dialogue lorsque l'utilisateur déplace la souris sur un élément, ou faire le même jugement logique lorsqu'une certaine touche du clavier est enfoncée. De cette façon, plusieurs gestionnaires d'événements exécutent la même logique, mais votre code est accidentellement copié plusieurs fois.

Un autre inconvénient du placement de la logique d'application dans les gestionnaires d'événements est lié aux tests. Lors des tests, vous devez déclencher directement le code de la fonction au lieu de simuler un clic sur l'élément. Si la logique de votre application est placée dans un gestionnaire d'événements, la seule façon de la tester est de déclencher l'événement. Bien que certains frameworks de tests puissent simuler des événements déclencheurs, en pratique, ce n’est pas la meilleure approche de test. La meilleure façon d’appeler du code fonctionnel consiste à utiliser un seul appel de fonction.

Vous devez toujours séparer la logique de l'application et le code de gestion des événements. Si vous souhaitez refactoriser l'exemple de code précédent, la première étape consiste à placer le code qui gère la logique de la boîte contextuelle dans une fonction distincte. Cette fonction est susceptible d'être montée sur un objet global défini pour l'application. Le gestionnaire d'événements doit toujours se trouver dans le même objet global. Il existe donc deux méthodes.

// 好的写法 - 拆分应用逻辑var MyApplication = {  handleClick: function (event) {    this.showPopup(event);
  },  showPopup: function (event) {    var pop = document.getElementById('popup');
    popup.style.left = event.clientX + 'px';
    popup.style.top = event.clientY + 'px';
    popup.className = 'reveal';
  }
};
addListener(element, 'click', function (event) {
  MyApplication.handleClick(event);
});

Toute la logique d'application précédemment contenue dans les gestionnaires d'événements est désormais déplacée dans la méthode MyApplication.showPopup(). Désormais, la méthode MyApplication.handleClick() ne fait qu'une seule chose : appeler MyApplication.showPopup(). Si la logique applicative est supprimée, les appels au même code fonctionnel peuvent se produire à plusieurs points, et il n'est pas nécessaire de s'appuyer sur le déclenchement d'un événement spécifique, ce qui est évidemment plus pratique. Mais ce n'est que la première étape pour décomposer le code du gestionnaire d'événements.

Règle 2 : Ne pas distribuer d'objets d'événement

Après avoir supprimé la logique de l'application, il y a toujours un problème dans l'exemple de code ci-dessus, c'est-à-dire que les objets d'événement sont distribués de manière incontrôlable. Il transmet MyApplication.handleClick() du gestionnaire d'événements anonyme, qui le transmet ensuite à MyApplication.showPopup(). Comme mentionné ci-dessus, l'objet événement contient de nombreuses informations supplémentaires liées à l'événement, et ce code n'en utilise que deux. La logique de l'application ne doit pas s'appuyer sur l'objet événement pour terminer la fonction correctement pour les raisons suivantes : L'interface de la méthode

n'indique pas quelles données sont nécessaires. Une bonne API doit être transparente sur les attentes et les dépendances. Passer un objet événement en paramètre ne vous indique pas quelles propriétés de l'événement sont utiles et à quoi elles servent

Par conséquent, si vous souhaitez tester cette méthode, vous devez recréer un objet événement et le transmettre ? comme paramètre entrez. Par conséquent, vous devez savoir exactement quelles informations cette méthode utilise afin de pouvoir écrire correctement le code de test.

Ces problèmes (faisant référence à un format d'interface peu clair et à des objets d'événement auto-construits pour les tests) ne sont pas recommandés dans les applications Web à grande échelle. Le manque de clarté du code peut entraîner des bugs.

La meilleure façon est de laisser le gestionnaire d'événements utiliser l'objet événement pour gérer l'événement, puis d'obtenir toutes les données requises et de les transmettre à la logique de l'application. Par exemple, la méthode MyApplication.showPopup() ne nécessite que deux éléments de données, la coordonnée x et la coordonnée y. De cette façon, on réécrit la méthode pour qu'elle reçoive ces deux paramètres.

// 好的写法var MyApplication = {  handleClick: function (event) {    this.showPopup(event.clientX, event.clientY);
  },  showPopup: function (x, y) {    var pop = document.getElementById('popup');
    popup.style.left = x + 'px';
    popup.style.top = y + 'px';
    popup.className = 'reveal';
  }
};
addListener(element, 'click', function (event) {
  MyApplication.handleClick(event);
});

在这段新重写的代码中，MyApplication.handleClick()将x坐标和y坐标传入了MyApplication.showPopup()，代替了之前传入的事件对象。可以很清晰地看到MyApplication.showPopup()所期望传入的参数，并且在测试或代码的任意位置都可以很轻易地直接调用这段逻辑，比如：

// 这样调用非常棒MyApplication.showPopup(10, 10);

当处理事件时，最好让事件处理程序成为接触到event对象的唯一的函数。事件处理程序应当在进入应用逻辑之前针对event对象执行任何必要的操作，包括阻止默认事件或阻止事件冒泡，都应当直接包含在事件处理程序中。比如：

// 好的写法var MyApplication = {  handleClick: function (event) {    // 假设事件支持DOM Level2
    event.preventDefault();
    event.stopPropagation();    // 传入应用逻辑
    this.showPopup(event.clientX, event.clientY);
  },  showPopup: function (x, y) {    var pop = document.getElementById('popup');
    popup.style.left = x + 'px';
    popup.style.top = y + 'px';
    popup.className = 'reveal';
  }
};
addListener(element, 'click', function (event) {
  MyApplication.handleClick(event);
});

在这段代码中，MyApplication.handleClick()是事件处理程序，因此它在将数据传入应用逻辑之前调用了event.preventDefault()和event.stopPropagation()，这清除地展示了事件处理程序和应用逻辑之间的分工。因为应用逻辑不需要对event产生依赖，进而在很多地方都可以轻松地使用相同的业务逻辑，包括写测试代码。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

怎样利用JS做出引用传递与值传递

如何做出node.js界面

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!