JavaScript 瀏覽器事件解析

keelii發表於2016-10-03

JavaScript、瀏覽器、事件之間的關係

JavaScript 程式採用了非同步事件驅動程式設計(Event-driven programming)模型,維基百科對它的解釋是:

事件驅動程式設計(英語:Event-driven programming)是一種電腦程式設計模型。這種模型的程式執行流程是由使用者的動作(如滑鼠的按鍵,鍵盤的按鍵動作)或者是由其他程式的訊息來決定的。相對於批處理程式設計(batch programming)而言,程式執行的流程是由程式設計師來決定。批量的程式設計在初級程式設計教學課程上是一種方式。然而,事件驅動程式設計這種設計模型是在互動程式(Interactive program)的情況下孕育而生的

簡頁言之,在 web 前端程式設計裡面 JavaScript 通過瀏覽器提供的事件模型 API 和使用者互動,接收使用者的輸入

由於使用者的行為是不確定的,也就是說不知道使用者什麼時候發生點選、滾動這些動作。這種場景是傳統的同步程式設計模型沒法解決的,因為你不可能等使用者操作完了才執行後面的程式碼

比如我們在 Python 裡面呼叫接收使用者輸入的方法 raw_input() 後終端就會一直等待使用者的輸入,直到輸入完成才會執行後面的程式碼邏輯。但是在下面這段 NodeJS 程式碼中,接收使用者輸入的方法 process.stdin.read 是在一個事件中呼叫的。後面的程式碼不會被阻塞(blocked)

事件驅動程式模型基本的實現原理基本上都是使用 事件迴圈(Event Loop),這部分內容涉及瀏覽器事件模型、回撥原理,有興趣的去看連結裡面的視訊學習下

需要說明的是在客戶端 JavaScript 中像 setTimeout, XMLHTTPRequest 這類 API 並不是 JavaScript 語言本身就有的。而是 JavaScript 的宿主環境(在客戶端 JavaScript 中就是瀏覽器),同樣像 DOM、BOM、Event API 都是瀏覽器提供的

事件繫結的方法

DOM 元素行內繫結

直接在 DOM 元素上通過設定 on + eventType 來繫結事件處理程式

這種繫結方法是最原始的,有兩個缺點:

1 事件處理程式和 HTML 結構混雜在一起

早期在結構、樣式、表現分離的時代很忌諱這一點。現在看來在很多 MVX 框架中將事件繫結和 DOM 結構放在一起處理,這樣似乎更方便維護(不用來回切換 HTML,JavaScript 檔案),而且也符合可預見(predictable)性的規則

2 名稱空間衝突

因為 onclick 中的 JavaScript 程式碼片段執行環境是全域性作用域。然而在 JavaScript 語言中並沒有相關的名稱空間特性。所以就很容易造成名稱空間的衝突,非要用這種方法繫結事件的話只能用物件來做一些封裝

古老的繫結方法

使用 DOM Element 上面的 on + eventType 屬性 API

這種方法也有一個缺點,因為屬性賦值會覆蓋原值的。所以無法繫結 多個 事件處理函式,如果我們要註冊多個 onload 事件處理程式的話就得自己封裝一個方法來防止這種事情發生,下面這個例子可以解決這個問題

注意這只是個示例,生產環境很少會用到。一般用 DOM Ready 就可以了,因為 JavaScript 的執行通常不用等到頁面資源全部載入完,DOM 載入完就可以了

現代/標準的繫結方法

標準的繫結方法有兩種,addEventListenerattachEvent 前者是標準瀏覽器支援的 API,後者是 IE 8 以下瀏覽器支援的 API。通常需要我們做個相容封裝

上面的例子在 IE 8 以下和標準瀏覽器的效果是不一樣的,問題就在於 addEventListener 中的事件回撥函式中的 this 指向元素(target)本身,而 attachEvent 則指向 window 為了修復這個問題上面的 attachEvent 可以做一點小調整讓其保持和 addEventListener 的效果一樣,不過這樣的話註冊的 handler 就是個匿名函式,無法移除

當上面這幾種情況同時出現的時候就比較有意思了,可以試試下面這段程式碼的你輸出

正確的結果應該是 3,4,5,1,根據結果我們可以得出以下結論:

  • 連結上的 href 偽 javascript 協議相當於在瀏覽器位址列執行了一段 JavaScript 程式碼,連結如果是這種格式,點選的時候相當於執行了這段 JavaScript 指令碼
  • 行內的事件繫結和元素呼叫 onclick 繫結事件會覆蓋
  • 使用 jQuery(內部使用標準事件註冊 API)可以繫結多個事件處理程式

事件冒泡

大部分事件會沿著事件觸發的目標元素往上傳播。比如:body>div>p>span 如果他們都註冊了點選事件,那麼在 span 元素上觸發點選事件後 p,div,body 各自的點選事件也會按順序觸發

事件冒泡是可以被停止的,下面這個函式封閉了停止事件冒泡的方法:

事件物件

標準瀏覽器中在事件處理程式被呼叫時 事件物件 會通過引數傳遞給處理程式,IE 8 及以下瀏覽器中事件物件可以通過全域性的 window.event 來訪問。比如我們要獲取當前點選的 DOM Element

事件代理

有時候我們需要給 不存在的(可能將來會有)的一段 DOM 元素繫結事件,比如給一段 Ajax 請求完成後渲染的 DOM 節點繫結事件。一般繫結的邏輯會在渲染前執行,繫結的時候找不到元素所以並不能成功,當然你也可以把繫結事件的程式碼放在 Ajax 請求之後。這樣做在一些事件邏輯簡單的應用裡面沒問題,但是會加重資料渲染邏輯和事件處理的邏輯耦合。一但事件處理程式特別多的時候,我們通常建議把事件的邏輯和其它程式碼邏輯分離,這樣方便維護。

為了解決這個問題,我們通常使用事件代理/委託(Event Delegation )。而且通常來說使用 事件代理的效能會比單獨繫結事件高 很多,我們來看個例子

假如 ul 中的 HTML 是 Ajax 非同步插入的,通常我們的做法是 插入完成後遍歷每個 li 繫結事件處理程式

我們再使用事件代理把事件繫結到 ul 元素上,我們知道很多事件可以冒並沿著 DOM 樹傳播到所有的父元素上,我們只需要判斷目標元素是不是我們想繫結的真正元素即可

顯然使用了事件代理之後,程式碼變少了。邏輯也很清晰,關鍵是以前需要 N 次的繫結操作現在只需要一次

jQuery 中的事件繫結

以 jQuery1.6.4 為例,jQuery 提供了很多事件繫結的 API。例如: delegate(), bind(), click(), hover(), one(), live(),這些方法其實都是一些別名,核心是呼叫了 jQuery 底層事件的 jQuery.event.add 方法。其實現也是上文提到的 addEventListenerattachEvent 兩個 API

這些 API 主要是為了方便繫結事件的各種場景,並且內部處理好了相容性問題。還有一個比較好用的地方就是 事件名稱空間。比如:兩個彈出層都向 document 繫結了點選關閉事件,但是如果只想解綁其中一個。這時候使用名稱空間再合適不過了。可以試試這個小例子 Event Binding

自定義事件與釋出/訂閱者設計模式

自定義事件是設計模式中的 釋出/訂閱者 的一種實現。釋出者與訂閱者鬆散地耦合,而且不需要關心對方的存在。這裡有 NC 大師的一種實現。實際使用過程中,主要被運用在非同步操作比較多的場景和不同系統之間訊息通訊,之前的文章中有過一些例項

引用

部落格同步原文:https://keelii.github.io/2016/09/29/javascript-browser-event/

相關文章