事件驅動的編程變得流行之前，在程序內部進行通信的標準方法非常簡單：如果一個組件想要向另外一個發送消息，只是顯式地調用了那個組件上的方法。但是在 react 中用的卻是事件驅動而不是調用。
事件的好處
這種方法能夠使組件更加分離。在我們繼續寫程序時，會識別整個過程中的事件，在正確的時間觸發它們，併為每個事件附加一個或多個事件監聽器，這使得功能擴展變得更加容易。我們可以為特定事件添加更多的 listener，而不必修改現有的偵聽器或觸發事件的應用程序部分。我們所談論的是觀察者模式。
觀察者模式
設計一個事件驅動的體系結構
對事件進行識別非常重要，我們不希望最終必須從系統中刪除或替換現有事件，因為這可能會迫使我們刪除或修改附加到事件上的眾多偵聽器。我的一般原則是僅在業務邏輯單元完成執行時才考慮觸發事件。
假如你想在用戶註冊後發送一堆不同的電子郵件。註冊過程本身可能會涉及許多複雜的步驟和查詢，但從商業角度來看，這只是其中的一個步驟。每個要發送的電子郵件也是單獨的步驟。因此，一旦註冊完成馬上就發佈事件是很有意義的。於是我們附加了多個監聽器，每個監聽器負責發送一種類型的電子郵件。
Node的異步事件驅動架構具有一些被稱為“emitters”的對象。它們發出命名事件，這些事件會調用被稱為“listener”的函數。發出事件的所有對象都是 EventEmitter 類的實例。使用它，我們可以創建自己的事件：
一個例子
讓我們使用內置的 events 模塊（我建議你查看這個文檔：https://nodejs.org/api/events.html）以獲取對 EventEmitter 的訪問權限。
1const EventEmitter = require('events');
2
3const myEmitter = new EventEmitter();
4
5module.exports = myEmitter;
這是我們的服務器端程序的一部分，它負責接收HTTP請求，保存新用戶併發出事件：
1const myEmitter = require('./my_emitter');
2
3// Perform the registration steps
4
5// Pass the new user object as the message passed through by this event.
6myEmitter.emit('user-registered', user);
附加一個監聽器的單獨模塊：
1const myEmitter = require('./my_emitter');
2
3myEmitter.on('user-registered', (user) => {
4 // Send an email or whatever.
5});
將策略與實現分開是一種非常好的做法。在這種情況下，策略意味著哪些 listener 訂閱了哪些事件。實現意味著 listener 自己。
1const myEmitter = require('./my_emitter');
2const sendEmailOnRegistration = require('./send_email_on_registration');
3const someOtherListener = require('./some_other_listener');
4
5myEmitter.on('user-registered', sendEmailOnRegistration);
6myEmitter.on('user-registered', someOtherListener);
1module.exports = (user) => {
2 // Send a welcome email or whatever.
3}
這種分離使 listener 也可以被重複使用，它可以被附加到發送相同消息的其他事件上（用戶對象）。同樣重要的是 當多個 listener 被附加到單個事件時，它們將按照附加的順序同步執行。因此 someOtherListener 將在 sendEmailOnRegistration 完成執行後運行。
但是，如果你希望自己的 listener 以異步方式運行，只需用 setImmediate 包裝它們的實現，如下所示：
1module.exports = (user) => {
2 setImmediate(() => {
3 // Send a welcome email or whatever.
4 });
5}
讓你的 Listeners 保持簡潔
在寫 listener 時要堅持單一責任原則。一個 listener 應該只做一件事並把事情做好。例如：要避免在 listener 中編寫太多的條件並根據事件傳來的數據（消息）去決定做什麼。在這種情況下使用不同的事件會更加合適：
1const myEmitter = require('./my_emitter');
2
3// Perform the registration steps
4
5// The application should react differently if the new user has been activated instantly.
6if (user.activated) {
7 myEmitter.emit('user-registered:activated', user);
8
9} else {
10 myEmitter.emit('user-registered', user);
11}
1const myEmitter = require('./my_emitter');
2const sendEmailOnRegistration = require('./send_email_on_registration');
3const someOtherListener = require('./some_other_listener');
4const doSomethingEntirelyDifferent = require('./do_something_entirely_different');
5
6
7myEmitter.on('user-registered', sendEmailOnRegistration);
8myEmitter.on('user-registered', someOtherListener);
9
10myEmitter.on('user-registered:activated', doSomethingEntirelyDifferent);
11view raw
必要時明確分離 Listener
在前面的例子中，我們的 listener 是完全獨立的函數。但是在 listener 與對象關聯的情況下（這時是一種方法），必須手動將其從已訂閱的事件中分離出來。否則對象將永遠不會被垃圾回收，因為對象（ listener ）的一部分將會繼續被外部對象（ emitter ）引用，所以存在內存洩漏的可能。
例如，如果我們正在開發一個聊天程序，並且希望當新消息到達用戶進入的聊天室時，顯示通知的功能應該位於該用戶對象本身的內部，我們可能會這樣做：
1class ChatUser {
2
3 displayNewMessageNotification(newMessage) {
4 // Push an alert message or something.
5 }
6
7 // `chatroom` is an instance of EventEmitter.
8 connectToChatroom(chatroom) {
9 chatroom.on('message-received', this.displayNewMessageNotification);
10 }
11
12 disconnectFromChatroom(chatroom) {
13 chatroom.removeListener('message-received', this.displayNewMessageNotification);
14 }
15}
當用戶關閉他的標籤或暫時斷開互聯網連接時，我們可能希望在服務器端發起一個回調，通知其他用戶有人剛剛下線。當然在這時為脫機用戶調用 displayNewMessageNotification 沒有任何意義。除非我們刪除它，否則它將繼續被用於調用新消息。如果不這樣做，除了不必要的調用之外，用戶對象也會被永久地保留在內存中。因此在用戶脫機時應該在服務器端回調中調用disconnectFromChatroom。
注意事項
如果不小心，即便是鬆散耦合的事件驅動架構也會導致複雜性的增加，可能會導致在系統中跟蹤依賴關係變得很困難。如果我們從偵聽器內部發出事件，程序會特別容易出現這類問題。這可能會觸發意外的事件鏈。
十五年編程經驗，今年1月整理了一批2019年最新WEB前端教學視頻，不論是零基礎想要學習前端還是學完在工作想要提升自己，這些資料都會給你帶來幫助，從HTML到各種框架，幫助所有想要學好前端的同學，學習規劃、學習路線、學習資料、問題解答。只要關注我的頭條號，後臺私信我【前端】兩個字，即可免費獲取。
閱讀更多 前端技術教學分享 的文章
