jQuery事件處理: 別再亂用“return false”了
可能在你剛開始學習關於jQuery事件處理時,看到的第一個例子就是關於如何阻止瀏覽器執行預設行為,比如下面這段演示click事件的程式碼:
- $("a.toggle").click(function () {
- $("#mydiv").toggle();
- returnfalse; // Prevent browser from visiting `#`
- });
這個函式使用toggle來顯示或者隱藏#mydiv,然後阻止瀏覽器繼續訪問href中指定的連結。
像上面這樣的例子會讓使用者養成使用“return false”來阻止瀏覽器執行預設行為的壞習慣,在這篇文章裡,我將會討論關於阻止瀏覽器執行預設行為的兩個非常重要的主題:
- 選擇正確的方法: return false還是preventDefault,stopPropagation或者stopImmediatePropagation
- 選擇合適的位置,開始,結束,還是中間某個地方:你應該在事件回撥的哪個部分取消瀏覽器執行預設行為?
注意:當我在這篇文章中提到event bubbling(事件冒泡),我想表達的是大部分事件都是先在初始DOM上觸發,然後再通過DOM樹往上,在每一級父元素上觸發,事件不會在兄弟節點或 是子節點上冒泡(當事件向下冒泡時,我們叫它事件捕捉(event capturing)),你可以在這裡瞭解更多關於事件起泡和捕捉的介紹。
選擇正確的方法
“return false”之所以被誤用的如此厲害,是因為它看起來像是完成了我們交給它的工作,瀏覽器不會再將我們重定向到href中的連結,表單也不會被繼續提交,但這麼做到底有什麼不對呢?
”return false“到底做了什麼?
當你每次呼叫”return false“的時候,它實際上做了3件事情:
- event.preventDefault();
- event.stopPropagation();
- 停止回撥函式執行並立即返回。
“等等”,你叫了起來!我只是想讓瀏覽器停止繼續執行預設行為而已,我不需要它去做另外2件事。
這3件事中用來阻止瀏覽器繼續執行預設行為的只有preventDefault,除非你想要停止事件冒泡,否則使用return false會為你的程式碼埋下很大的隱患,讓我們通過一個真實的例子來看看這樣的誤用會造成什麼後果:
這是我們用來演示的HTML:
- <div
- <h2><ahref="http://heikezhi.com/path/to/page">My Page</a></h2>
- <divclass="content">
- Teaser text...
- </div>
- </div>
- <divclass="post">
- <h2><ahref="http://heikezhi.com/path/to/other_page">My Other Page</a></h2>
- <divclass="content">
- Teaser text...
- </div>
- </div>
現在假設我們想要在使用者點選文章標題時,將文章動態載入到div.contentd中:
- jQuery(document).ready(function ($) {
- $("div.post h2 a").click(function () {
- var a = $(this),
- href = a.attr('href'), // Let jQuery normalize `href`,
- content = a.parent().next();
- content.load(href + " #content");
- returnfalse; // "cancel" the default behavior of following the link
- });
- });
這段程式碼可以正常工作(至少目前是),但如果我們順著這個思路繼續,如果我想要在使用者點選了一個div.post元素(或者任何一個它的子元素)時,給它加上一個active類,我就需要給div.post增加了一個click回撥:
- // Inside Document Ready:
- var posts = $("div.post");
- posts.click(function () {
- // Remove active from all div.post
- posts.removeClass("active");
- // Add it back to this one
- $(this).addClass("active");
- });
現在,如果我們點選一個帖子的標題,這段程式碼會工作嗎?答案是不會,因為我們在標題的click回撥裡使用了return false而不是我們應該使用的,”return false“等於event.preventDefault();加event.stopPropagation();,所以事件冒泡就被終止 了,click事件不會被冒泡到div.post上,我們為它新增的事件回調當然也就不會被呼叫了。
如果我們把它和live或者delegate事件混在一起使用時,情況就更糟了。
- $("a").click(function () {
- // do something
- returnfalse;
- });
- $("a").live("click", function () {
- // THIS WON'T FIRE
- });
那麼我們真正需要的是什麼呢?
preventDefault()
大多數情況下,當你使用return false時,你其實真正需要的是e.preventDefault()。要使用e.preventDefault,你需要確保你傳遞了event引數到你的回掉函式中(在這個例子裡,就是那個e):
- $("a").click(function (e) {
- // e == our event data
- e.preventDefault();
- });
它會替我們完成所有工作,但不會阻止父節點繼續處理事件,要記住,你放在程式碼中的限制越少,你的程式碼就越靈活,也就越易於維護。
stopPropagation()
但有些情況下,你有可能需要停止事件冒泡,讓我們看看下面的例子:
- <divclass="post">
- Normal text and then a <ahref="http://heikezhi.com/path">link</a> and then more text.
- </div>
現在,讓我們假設如果你點了div上除了a連結之外的地方,我們希望能發生點什麼事情(比如改變下背景什麼的),但是不能影響使用者點選a連結的行為(從可用性的角度,這個例子不怎麼好,你可能不希望使用者點選別的地方時發生任何事情)。
- $("div.post").click(function () {
- // Do the first thing;
- });
- $("div.post a").click(function (e) {
- // Don't cancel the browser's default action
- // and don't bubble this event!
- e.stopPropagation();
- });
在這種情況下,如果我們使用return false,div的click事件不會被觸發,但是使用者也不會到達他們點的那個連結。
stopImmediatePropagation()
這個方法會停止一個事件繼續執行,即使當前的物件上還綁定了其它處理函式,所有繫結在一個物件上的事件會按繫結順序執行,看看下面的例子:
- $("div a").click(function () {
- // Do something
- });
- $("div a").click(function (e) {
- // Do something else
- e.stopImmediatePropagation();
- });
- $("div a").click(function () {
- // THIS NEVER FIRES
- });
- $("div").click(function () {
- // THIS NEVER FIRES
- });
你可能會覺得這個例子看起來很彆扭,沒錯,儘管如此,但有時這的確會發生,如果你的程式碼非常複雜,那麼不同的widgets和plugin就有可能在同一個物件上新增事件,如果遇到這種情況,那你就很有必要理解和使用stopImmediatePropagation。
return false
只有當你同時需要preventDefault和stopPropagation,並且你的程式碼可以接受直到你的回撥執行完成才停止執行瀏覽器的默 認行為,那你就可以使用”return false“。但我強烈建議你別在寫給其它jQuery開發者的演示程式碼中使用這個方法,因為這會造成更多誤用,只有在你確信非用不可的情況下再去使 用”return false“。
選擇適當的位置
如果你使用了”return false“,它只會在你的回撥函式執行結束才去取消瀏覽器的預設行為,但是使用e.preventDefault,我們有更多的選擇,它可以隨時停止瀏覽器執行預設動作,而不管你將它放在函式的哪個部分。
1. 開發階段,你應該總是將它放在第一行。你最不想做的事情可能就是你正在除錯將一個form改成ajax提交的時候,它卻已經被按照老方法提交了。
2.產品階段,如果你採用了漸進增強(progressive enhancement),那就把它放到回撥的 結束位置,或者是邏輯終點,如果在一個普通頁面採用漸進增強,那你就需要在伺服器端考慮如果瀏覽器不支援JS時(或者被禁用時),對連結的click事件 和表單的提交事件的處理。這裡的好處是,我們不考慮關閉JS的情況,只考慮支援js時的強狂,如果你的回撥程式碼出錯丟擲了異常,讓我們看看下面的程式碼:
- var data = {};
- $("a").click(function (e) {
- e.preventDefault(); // cancel default behavior
- // Throws an error because `my` is undefined
- $("body").append(data.my.link);
- // The original link doesn't work AND the "cool"
- // JavaScript has broken. The user is left with NOTHING!
- });
現在,讓我們看看同樣的事件,把preventDefault呼叫放在底部的效果:
- >
- var data = {};
- $("a").click(function (e) {
- // Throws an error because `my` is undefined
- $("body").append(data.my.link);
- // This line is never reached, and your website
- // falls back to using the `href` instead of this
- // "cool" broken JavaScript!
- e.preventDefault(); // cancel default behavior
- });
這對錶單提交也同樣有效,你可以更好的應對出錯的情況,別指望你的程式碼一直正常工作,在發生錯誤時有正確的應對總勝過假設程式碼不會出錯。
3. 在產品階段,如果功能這設計JS,那就還應該放在第一行。
記住,不必非得是函式的第一行,但是越早越好,這裡的原則是:如果函式的功能是通過JS實現的(不涉及服務端互動),那就沒必要考慮相容,在這種情 況下,新增在第一行可以防止URL中出現#字元,但顯然,你還是應該儘可能多的增加些錯誤處理程式碼,以防止使用者在出錯時變得不知所措。
結論
我希望這篇文章傳達的資訊足夠你在需要阻止瀏覽器執行預設行為時做出正確的選擇。記住,只有當你真的明白你在做什麼時,才使用”return false“,並確保你是在函式的正確位置呼叫了相應的程式碼。最後,儘可能保持程式碼的靈活性,儘量不要再用“return false”了!