15
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

HTMLへonClickを記述しないメリット

Posted at

イベントリスナの登録

一般的にHTML上の要素にイベントリスナを登録する方法は、
https://developer.mozilla.org/ja/docs/Web/API/Event
によると3種類

  • EventTarget.addEventListener
  • HTMLのon***属性(onClickとか)
  • DOMのプロパティ

とのことです。

現在やってるプロジェクトではコーディング規約でHTMLのon***に書けってことになってます。

しかし、この方式は先ほどのmdnのページによると

この方法は避けるべきです。これはマークアップを大きくし、読みづらくします。「コンテンツ/構造」と「ふるまい」の関係がうまく切り離されません。そして、見つけるのが難しいバグをつくります。

と記載され、最も推奨されない記述方法のようです。

構造と振る舞いの関係が切り離されない。はそのとおりだと思います。
しかし、

見つけるのが難しいバグを作ります。

ってどんなんだろうと思ってたらプロジェクトで踏んだっぽいのでどういうことがおきたか記事化しておきます。

ページの構築中に処理を始められた。

仮にaddEventListenerの登録であれば、画面遷移時の処理は

1.DOMの構築完了
2.イベントリスナの登録

という順序であれば、画面のボタンやフォームが構築される途中で何をしてもイベントリスナを設定していないので何も起こらないハズ。

ところが、
HTMLにonClickなどが書かれていると、ボタンやフォームが構築される途中でボタンを押下するなどのユーザ操作で、ボタンに設定したイベントリスナからjavascriptの処理が開始可能になってしまう。

具体的には

sample
<form action="/hoge">
<input name="foo">
<input name="bar">
</form>

の状態でformされるのを期待しているのに、

sample
<form action="/hoge">
<input name="foo">

位の状態でリクエストが飛んだり、まだDOMに構築していない要素の更新を試みてこけていた。

そのためサーバサイドでは、アプリケーション上想定してないパラメータの欠落等が発生していた。

対応

ベタベタですが画面の操作を抑止する処理とonLoad後に画面の抑止を解除して対応した。
ベストプラクティスには乗っかっておいたほうがやはり無難だなぁ。

15
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?