はじめに

javascriptやjqueryを使用してwebページを作成していますが、時々、デバックをしていて、なぜ、あのclcikイベントリスナーでブレークしないのだろうと悩むことがあります。何とか調べてやっと、アァー、あのクリックは、ここに来ていたのかと理解することがあります。その辺のことを以下に書いてみたいと思います。

いつも使用しているイベントリスナー

いつもは、jqueryを使って、以下のようなスクリプトを書いています。

//ボタンイベントリスナー
$(".my_list").on('click',()=>{
....
ここに,処理を記述
...

});

大抵は、この構文でリスナーを定義しています。
または、document.addEventListener(.....)とかを使っています。
そのため、デバッグでは、リスナーの直後にalert()文を入れたりしています。

//ボタンイベントリスナー
$(".my_list").on('click',()=>{
alert("btnイベントが発火しました。");
....
ここに,処理を記述
...

関係するリスナーのすべての個所にこのようなalert();文を入れて、ボタンをクリックしたときに、どのイベントリスナーに飛んできたのかを確認しています。

今回もすべてのリスナー個所にalert()文をセットしたつもりでした。
ところが、ボタンをクリックしても、どこもブレークしません。
なぜなんだろうと、何度も関係個所のalert()文をチェックしました。
どこもおかしくありません。

いったい、どのルートを通って処理が続行してしまっているのだろうと。
ブレークせずに処理が先に進んでいます。

$(".my_list").on('click',..が定義されているのか、他のjsファイルも見てみましたが、そのような個所はありません。
何度、テストしてもブレークせずに、先に進んでいます。
途方にくれました。

もしかしたらと

そこで、ハタと気がつきました。確か、以前も似たような現象があったと、思い出しました。もしかしたらと、当時のことをおもいだしました。
確か、"#my_list"でも、".my_list"セレクターでもなかったような、たしかmy_listだけで見ていたような気がすると思い出しました。

リスナーの場所をさがすため、ツールやデバッガーの検索では、".my_list"というキーワードで検索していました。これでは、"my_list"は見つかりません。
試しに"my_list"だけで、検索してみました。
すると、出てきました。

場所が見つかりました。

//ここにありました。
switch (e.target.className) {
   case "my_list":

ありました。ここに、リスナーが定義されていました。
これは、$("#block").on('click',()=>{........})というところで、定義していました。
てっきり、$(".my_list").on('click',()=>{.....})で、リスナーを定義していると思っていましたので、まさか、case "my_list":で、定義しているとは思っていませんでした。それを作成していたのをすかっかり、忘れていました。
ページの"#block"セレクターには、".my_list"セレクターも含まれています。
それで、"#block"セレクターのイベントリスナーで、e.target.classNameが"my_list"の時に、リスナー処理を定義していました。

ちょっと、いつもと違う形式のリスナー定義をしていたため、思わぬ遠回りをしてしまいました。

テストしたwebページ

このテストは、以下のサイトのページで行いました。
chromeのデバッグ　コンソールで確認することができます。

mainサイト

反省

これは、反省というよりは、知識を広めたということかもしれません。
リスナーの定義の仕方は、いろいろあるということです。
広い範囲の要素内にある、ボタンのリスナー定義の時、親に当たる要素で、クリックしたときに、その処理内で、個々ボタンのclass属性を見て、リスナーを定義したときに発生します。
これは、「木を見て森を見ず」という故事と同じかもしれません。

あとがき

デバッグで、ブレークが効かないという現象には、よく出会います。
大抵は、思い違いとか、そこへは、来ない抜け道(ルート)があるとかで、素通りしていることが多いです。
思い込みが実に多いです。思い込んでいると堂々巡りなり、中々、そこから抜けだせません。この思考回路から抜け出すには、パソコンのように再起動してしまうのがいいかもしれません。