第二篇介紹了 State Machine，知道它是管理狀態、決定切換的機制。
但光有 State Machine 還不夠，因為 State Machine 不會主動去感知外界發生了什麼事。
這篇要介紹的就是負責感知外界的角色：Listener。
Listener 是什麼？
State Machine 知道有哪些狀態、知道切換的條件是什麼——但它自己沒有眼睛、沒有耳朵，它不會主動去感知外面發生了什麼事。
例如，上一篇我們知道車站驗票閘門有「關閉」和「打開」兩個狀態
閘門知道「刷卡成功」就打開門，但它怎麼知道你刷卡了？
答案是它還需要「感應器」！
它需要一個偵測 「有卡靠近」這個行為的感應器。
這個感應器一直在等待，等到偵測到這個行為發生的那一刻，才通知閘門「刷卡成功」。
此外，它還需要另一個偵測「有人通過」這個行為的感應器。
這個感應器一直在等待，等到偵測到這個行為發生的那一刻，才通知閘門「有人通過」。
所以閘門是靠著這些感應器的幫助，才能知道條件滿足、可以切換狀態了。
而這些感應器，就是 Listener——一個耳朵，專門負責聆聽有什麼事正在發生。
Listener 也是另一個常出現在程式裡的概念。
你平常上網時，當你點擊按鈕、滑鼠移過選單、在輸入框打字，背後都有程式碼在偵測你的每一個操作。這些偵測的機制，就叫做 Listener。
Listener 的工作很單純：盯著某件事，一旦偵測到它發生，就觸發對應的反應。
在 Rive 裡，Listener 可以盯著使用者的行為（例如滑鼠移入、點擊）。
一旦偵測到該行為，就會以某種方式讓整個系統知道「這件事發生了」。
那具體是怎麼運作的？先賣個關子，等一下會說清楚。
但光有 State Machine 和 Listener 還不夠，還需要「資料」
第二篇我們也提到，自動販賣機有「等待投幣」、「等待選擇」、「出貨中」等狀態。
而販賣機的投幣口就是一個 Listener，負責偵測「有硬幣投入」這件事。
但光偵測到「有硬幣投入」不夠，販賣機還需要知道：到目前為止總共投了多少錢？
你投了 10 元，它要記住 10；你再投 5 元，它要更新成 15。這個金額必須用一筆資料來記錄。
用狀態來表示金額不是不行，但如果金額範圍一大，狀態數量就會爆炸。
0 元一個狀態、1 元一個狀態、2 元一個狀態……這樣設計下去沒完沒了。
狀態適合用來描述「現在是什麼情況」，像是「正在等待投幣」或「正在等待選擇」，不適合用來追蹤「目前累積了多少錢」這種會一直變動的數值。
有了這筆資料，當使用者選擇了某個商品，State Machine 才能判斷：15 元夠不夠買這個商品？
夠的話，切換到「出貨中」狀態；不夠的話，繼續「等待投幣」狀態。
所以 Listener 和 State Machine 之間，其實並非直接溝通的關係，而是透過資料串起來的。
箭頭指示資料流動的方向。
Listener 偵測到使用者的行為後，去改寫一筆資料；
State Machine 根據這筆資料的變化，判斷條件是否滿足、要不要切換狀態。
而且不只是判斷條件需要資料。
想想你手機上的天氣 App，畫面顯示「東京，29°C，晴朗」。
這些數字不是設計師寫死的，是氣象局的伺服器提供的真實資料。
設計師做的事情是：在畫面上開好位置，定義好「這裡放城市名稱」、「這裡放溫度」、「這裡放天氣狀態」，然後讓資料自動流進來。
不管是用來判斷狀態切換的資料，還是用來顯示在畫面上的資料，都需要一個地方來定義和管理。這就是 View Model 在做的事。
下一篇，我們會介紹 View Model——那筆讓整個系統串起來的資料。