《AngularJS深度剖析與最佳實踐》一2.11 消息

本節書摘來自華章出版社《angularjs深度剖析與最佳實踐》一書中的第2章，第2.11節，作者 雪狼 破狼 彭洪偉，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視

在傳統的dom程式設計中，消息（message）機制非常有用，特别是消息冒泡機制，讓我們不用額外的代碼就可以實作“職責鍊”模式。但是我們要盡量擺脫dom操作，難道這是必須使用dom操作的場景嗎？不是的，angular中也有一種不依賴dom的消息機制，本節中我們就對它進行詳細講解。

我們知道，scope也被組織成了一棵樹，跟dom樹具有相似的結構。angular的消息機制就是通過scope上的幾個函數實作的：

$broadcast(name, args)：向目前scope及其所有下級scope遞歸廣播名為name的消息，并帶上args參數。

$emit(name, args)：向目前scope及其所有直線上級scope發送名為name的消息，并帶上args參數。

$on(name, listener)：監聽本scope收到的消息，listener的形式為：function(event, args) {}，event參數的結構和dom中的event類似。

以圖2-1所示的結構的scope為例：

當我們在rootscope上調用$broadcast廣播一個消息時，任何一個scope（包括rootscope）上通過$on注冊的listener都将收到這個消息。當我們在scope1上調用$broadcast廣播一個消息時時，scope1/scope1.1/scope1.2将依次收到這個消息。當我們在

rootscope上調用$emit上傳一個消息時，rootscope将收到這個消息。當我們在scope1.1上調用$emit上傳一個消息時，scope1.1/scope1/rootscope将依次收到這個消息。

當通過$emit上傳一個消息時，将使用冒泡機制，比如，假設我們在scope1.1上調用$emit，我們在scope1上注冊一個listener：

這個stoppropagation函數将阻止冒泡，也就是說scope1.1和scope1都将正常接收到這個消息，但rootscope就接收不到這個消息了。

有時候，用消息機制和普通回調函數都能達到類似的效果，如何選擇呢？

當一個嵌套結構具有樹形的業務含義時，我們就優先使用消息機制來通訊。或者從另一個角度看，符合“職責鍊”模式的适用場景時，消息機制比較合适。反之，應該使用普通的回調函數。

如果難以決定使用消息還是回調函數，那麼就優先使用回調函數（主要是angular事件），因為這種情況下執行路徑比較明确，容易跟蹤。或者在對此有深入了解前，先使用表面的判斷方式：一個事件是否需要被很多地方處理？調用stoppropagation是否有意義？如果是，那麼用消息，否則用回調。