関数を実行したい場合は、インライン js を使用することを好みます。
<p id="element" onclick="doSomething();">Click me</p>
デバッグしやすいからです。
ただし、インライン js を使用しないように言っている人がいるのを聞いて、次のようにします。
document.getElementById('element').onclick = doSomething;
js イベントリスナーが推奨されるのはなぜですか?
関数を実行したい場合は、インライン js を使用することを好みます。
<p id="element" onclick="doSomething();">Click me</p>
デバッグしやすいからです。
ただし、インライン js を使用しないように言っている人がいるのを聞いて、次のようにします。
document.getElementById('element').onclick = doSomething;
js イベントリスナーが推奨されるのはなぜですか?
基本的には、すべてを別々に保つことと関係があると思います。したがって、HTML/CSS/JS をすべて分離してください。これにより、HTML が整理され、ナビゲートしやすくなります。
次に、大きな変更を加える必要がある場合は、インライン JS を外部ファイルに移動する必要がある十分なスペースがあります。または、同じ関数を複数のボタンに適用する場合は、コードが少なくなります。そして、少ないコードはより幸せな場所です
JS ファイルが適切に作成され、完全に文書化されていれば、外部の人がそれらをナビゲートするのは簡単になります。
インライン JavaScript を避ける理由はたくさんありますが、おそらく最も重要な理由の 1 つはコードの保守性です。
簡単な例 (デモ目的で jQuery を使用しています)。
<p class="element" onclick="doSomething();">Click me</p>
<p class="element" onclick="doSomething();">Click me</p>
<p class="element" onclick="doSomething();">Click me</p>
<p class="element" onclick="doSomething();">Click me</p>
<p class="element" onclick="doSomething();">Click me</p>
<p class="element" onclick="doSomething();">Click me</p>
突然、すべての段落を変更して別の機能を実行するように要求されたらどうしますか? あなたの例では、HTML コードのすべてを手動で変更する必要があります。ただし、HTML を JavaScript から分離することを選択した場合は、次のように単純に行うことができます。
<p class="element">Click me</p>
<p class="element">Click me</p>
<p class="element">Click me</p>
<p class="element">Click me</p>
<p class="element">Click me</p>
<p class="element">Click me</p>
$('.element').bind('click', doSomethingElse);
HTMLコードもすっきりしているため、デザイナーは、他の人が関与するプロジェクトに取り組んでいるときに実際に何かを壊してしまうのではないかと心配することなく、デザインに専念することができます.
編集:以下の私のコメントの例を提供します。
Project = {
// All the variables/constants/objects that need to be globally accessible inside the Project object.
init : function(){
// Main entry point...
this.MainMenu.init();
// Rest of the code which should execute the moment Project is initiated.
}
}
Project.MainMenu = {
// All the variables/constants/objects that need to be accessible only to MainMenu.
init : function(){ // Is run immediatelly by Project.init()
// Event handlers relevant to the main menu are bound here
// Rest of the initialization code
}
}
Project.SlideShow = {
// All the variables/constants/objects that need to be accessible only to SlideShow.
init : function(){ // Is run only on pages that really require it.
// Event handlers for the slideshow.
}
}
他の人がどう思うかもしれませんが、マークアップでリスナーをインライン化することには価値があると思います。具体的には、DOM ノードをより自由に変更できるようになります。JavaScript を使用してリスナーを追加している場合、親ノードの innerHTML を置き換えるとリスナーが失われます。マークアップでリスナーをインライン化する場合は、ノードを複製して変更を加え、元のノードを複製して変更したノードに置き換えることができます。
おそらく、特定のユースケースで説明する方が良いでしょう。リフローを複数回トリガーすることなく、ドキュメントの複数の部分に変更を加えたいです。したがって、この場合、ノードのクローンを作成し、それに変更を加え (デタッチされているためリフローなし)、前のノードを変更したノードに置き換えます (1 つのリフローをトリガーします)。インライン化されたリスナーを使用すると、これにより、置換中にリスナーが失われるのを防ぐことができます。
CSS とインライン スタイルについても同じことが言えます。現在のクラス/ID、または作業中の親/子要素を見つけるために css ファイルをくまなく調べる必要がないのは簡単です。
クリックをバインドして、10 個の異なるアイテムをインラインで表示する方が本当に良いのでしょうか? それとも、クラスを対象とする 1 つのイベント ハンドラーだけですか? 10 個のクリック ハンドラーが必要ない場合でも、コードを保守しやすくするように設定し、後でアップグレードすることをお勧めします。
私は、インラインハンドラーを使用することと、後でハンドラーをアタッチすることの利点を認識していません。私の経験では、動的要素を処理する必要がある場合は、インライン メソッドを使用することを好みます。たとえば、各画像にハンドラーを追加し、他のデータ (db の画像など) に従って画像の数を変更する場合などです。この場合、インラインを使用すると、各画像にハンドラーを追加できます。それ以外の場合は、javascript ファイル内の画像の数を再計算して、各画像に添付してハンドラーを処理する必要があります。
もちろん、要素のリストをインラインで簡単に取得できるjQueryのようなライブラリを使用できる場合は役に立ちません
イベント属性の代わりにイベント プロパティを使用する理由として、コンテンツ セキュリティ ポリシー (CSP) について誰も言及していないことに驚いています。それは、これまでに与えられた個人的な好みに勝ると思います。
適切に実装された場合 (つまり、まったくナンセンスな「unsafe-inline」を追加しない場合)、CSP1.0 は基本的にすべての形式のインライン スクリプトをブロックします。インライン イベント属性を不可能にします。CSP2.0 は、インライン スクリプトに「ノンス」を提供することでこれを改善しようとしますが、インライン イベント属性にはそのようなものを提供しません。CSP3.0 は、インライン イベントに「unsafe-hash」を追加しますが、まだ nonce の兆候はありません。
したがって、インライン イベントの nonce がない場合、イベント プロパティ (またはイベント リスナー) は、CSP の観点から非常に有効な方法です。