7

falseイベントコールバックから戻っていない場合、またはe.stopPropagationjQueryの機能を使用していない場合、イベントはDOMをバブルアップします。

ほとんどのシナリオでは、イベントがバブルするかどうかは気にしません。このDOM構造の例のように：

​<div id="theDiv">
    <form id="theForm" >
        <input type="submit" value="submit"/> 
    </form>
</div>​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

通常、私は次のような複数のネストされた送信コールバックを持っていません：

$('#theDiv').submit(function() {
    alert('DIV!');
});
$('#theForm').submit(function(e) {
    alert('FORM!');
    e.preventDefault();
});​

Fiddle
That DEMOはsubmitイベントバブルを<div>！
伝播を停止するか、デフォルトを防ぐだけでも、私には違いはありません。

これらのシナリオでは、伝播を停止すると、パフォーマンス上のメリットが得られますか？

4

3 に答える 3

6

パフォーマンス上のメリットはありますか？はい、 jQuerylive()とon()の間のこのパフォーマンステストで概説されているように、いくつかのわずかな利点があります。@Josephも指摘したように、この2つの違いは、ライブはツリー全体に伝播on()し、最も近い共通の親にのみ移動することです。

これらのテストでは、最大4倍のon()パフォーマンスを発揮できることが示されています。live()実際には、それでもまだ髪の毛を分割する価値はありませんが、非常に深いhtml構造と多くのイベントトリガーがある場合、伝播を停止する際のパフォーマンスの違いは価値があると思います。

于 2012-03-16T02:58:56.130 に答える
4

バブリングを伴うon()との比較と、jQuery が置き換えられた理由を次に示します。問題は、イベントがドキュメントに添付されていたため、ツリーを上ってハンドラーを見つけるのに長い旅が必要だったことです。できることは、ハンドラーを最も近い共通の親にアタッチできることです。これにより、ハンドラーを探すためにツリーを上る長い移動を回避できます。つまり、パフォーマンスが向上します。live()live()live()on()

ただし、独自のベンチマークを実行して確認することをお勧めします。

于 2012-03-16T02:30:19.810 に答える
2

このテストは、イベントを早期に強制終了することにはパフォーマンス上の利点があることを示しています。（15％-30％）そして、複雑なDOMにはおそらくもっと大きな違いがあるでしょう。また、イベントリスナーのキャプチャは、イベントの処理後にイベントをどのように処理するかに関係なく、イベントリスナーをバブリングするよりもわずかに高速であるように見えることにも注意してください。奇妙ですが面白いです。私は1つのブラウザでしかテストしませんでした

于 2012-04-26T14:39:32.497 に答える