1

これは、「単純な」Web サイトでのより良い方法です。(JavaScript アクションはほとんどありません)

a:イベント/アクション/関数を要素 (div/span/...) にアタッチするには

このボタンとクリック イベントが div にどのように追加されたかのように:

$( "#create-user" )
  .button()
  .click(function() {
  $( "#dialog-form" ).dialog( "open" );
  });

b: または、インラインで要素アクションが関数を呼び出すようにします。

<div id=calc onclick="doCalcFunc(this)">calc something</div>

これは、OO のバックグラウンドである Java/C# の出身者から質問されたもので、何が起こっているのかを簡単に見つけることができる単純な B を好むことがわかりました。単純に Web デバッグ ツールの詳細を学習することかもしれませんが、要素の [ソースに移動] をクリックして、この要素をクリックすると機能 X が実行されることを確認します。要素ID、タイプ、クラス、または要素のその他のインジケーターに関連付けられている可能性のある関数をソースで検索する必要があります。

4

2 に答える 2

1

ほとんどの場合、JS ベースのハンドラー割り当てを使用しますが、ハンドラー属性がうまく機能する場合もあります。

重要なのは、潜在的なツールを捨てるのではなく、両方の手法の長所と短所を知ることです。それぞれの「短所」に対比して検討してみようと思います。

要素属性ハンドラ

長所

  • ハンドラーは、ノードの作成後すぐに使用できます(ゼロ レイテンシー)。
  • 割り当ては非常に簡単で、非常に幅広いクロスプラットフォームをサポートしています。
  • CSS と重複しない要素へのフックを提供します(スタイルと動作の両方にクラスを使用)
  • 要素に関連付けられた動作のマークアップでの即時の可視性。

短所

  • 振る舞いと表現を混ぜ合わせます。
    • 反論:確かにそうですが、実際には大量の JavaScript を埋め込む場合にのみ問題になります。単一の関数呼び出しは、要素にクラスを追加することよりも邪魔になりません。
  • コードはevalすべてのイベントで実行されます。
    • カウンター:これは実際には真実ではありませんが、一般的に短所として述べられているので、含めようと思いました. 真実はeval、JavaScript の残りの部分と同じように、ページが読み込まれるときに 1 回実行されるということです。
  • 同じハンドラーを持つ複数の要素がある場合、関数を共有することはできませんが、各要素は一意の関数を取得します。
    • カウンター：これは本当です。関数呼び出しが同一であっても、要素ごと、イベントごとに新しい関数が作成されます。ただし、同じハンドラーを共有する複数のハンドラーがある場合は、イベントの委任が必要になる可能性があります。
  • 高いメンテナンス。関数への変更は、一致するようにマークアップを変更する必要があることを意味します。
    • カウンター:これは事実ですが、JavaScript コードにハンドラーを追加すると、クラス名の変更やマークアップの変更により DOM 選択が壊れるという同様の問題が発生する可能性があります。
  • 要素ごと、イベント タイプごとに 1 つのハンドラーのみを割り当てることができます。
    • カウンター:これは本当ですが、他の関数を呼び出す単一の汎用関数を使用できます。これは、jQuery が内部でどのように機能するかに多少似ています。
  • JavaScript で割り当てられたハンドラーと衝突する可能性があります。属性を割り当てるときonclick="foo()"、実際には に関数を割り当てていますelement.onclick。要素ごとに 1 つしか割り当てることができないため、JS でプロパティを変更すると、ハンドラーが上書きされます。
    • カウンター：これは本当です。これは間違いなく考慮に入れる必要がありますが、インラインまたは.onclickハンドラーを完全に却下する根拠として使用するべきではありません。競合が発生しない状況はたくさんあります。

JavaScript コードで割り当てられた jQuery ハンドラー

長所

  • jQuery は、非常にシンプルで互換性があります。
  • JavaScript とマークアップを直接混在させることはできません。
  • ハンドラーへの変更はすべて JavaScript で行われるため、複数の要素が関係している場合に繰り返し変更する必要はほとんどありません。
  • ブラウザー互換性修正プログラムが組み込まれています。

短所

  • DOM の準備ができた後にハンドラーが割り当てられた場合、JavaScript の動作なしで要素が表示される期間が生じる可能性があります。
    • 反論:事実ですが、これは多くの場合問題ではありません。低速の接続で大きなページを送信している場合、おそらく最も関連性があります。そのような場合、DOM 全体を待つのではなく、要素の近くにスクリプトを埋め込むことができます。
  • 非常に複雑な DOM 対応ソリューションが必要です。
    • カウンター:そうでもない。このようなソリューションを使用することを選択する人もいますが、ハンドラーを割り当てるスクリプトを単純にページの下部に配置できない理由はありません。
  • 最初のハンドラーを要素に追加すると、実際のハンドラーが複数の要素間で共有されている場合でも、jQuery は実際には別の関数を作成します。
    • カウンター:これは真実ですが、要素に割り当てられた最初のハンドラーにのみ当てはまります。割り当てられた追加のハンドラーは、jQuery が作成した「ボンネットの下」のハンドラーを共有するため、追加のオーバーヘッドは要素ごとに最初のハンドラーにのみ発生します。
  • クラスが JavaScript チームと CSS チームの両方で使用される可能性があり、どちらか一方がクラスの変更でコードを壊す可能性があるという、独自の「目障りな」問題があります。
    • 反論:そのような状況では、複数のクラスを命名規則とともに使用して、各チームにハンズオフ インジケーターを与えることができます。
  • 動作はマークアップからは見えません。
    • 反論:クラスがハンドラーの割り当て専用に使用され、適切な命名規則が使用されている場合、クラスはインライン ハンドラーと同じくらいわかりやすいものになる可能性があります。
  • JavaScript のためだけにクラスを追加することは、インライン ハンドラーを追加することと同じくらい目立ちます。
    • 反論:class="click_handler"実行することは実行することとあまり変わらないのは事実ですonclick="handler(this)"が、適切に設計された DOM を使用すると、クラスをまったく必要とせずに割り当てを実行できる可能性が非常に高くなります。(ただし、マークアップでの可視性の利点は失われます。)

そのため、どちらのアプローチにも宗教的な固執を避けるために懸命に努力している一方で、私は両方の方法でのいくつかの考慮事項の概要を提供しようとしました.

多くの場合、ハンドラーを割り当てるために、より一般的な DOM 対応のアプローチを使用していることに気付くかもしれませんが、特にゼロ レイテンシーの側面が重要な場合は、インライン ハンドラーがうまく適合する状況があります。

于 2013-04-22T15:43:06.067 に答える