RxJS 與元件層：把 props 當成一條 stream

1. 開場：這場 talk 的路線圖 0:17–1:56

講者 Fahad 在 traffics 用 React + RxJS 上線，先問現場有多少人在 production 用 React/Vue（很多）、用 RxJS（很少），點出這個落差就是這場 talk 要補的。他預告四件事：什麼是 data stream、RxJS 為什麼有價值、如何把 stream 接進 component 層、以及離開這個房間之後怎麼在 production 用。

推理作者一開場先做現場調查，因為他要建立的不是「RxJS 很好」而是「你們之間有個落差」：舉手用 React/Vue 的很多，用 RxJS 的很少。這個落差就是整場的動機——不是叫大家換框架，而是把 RxJS 放進大家已經有的元件層。他接著把 talk 拆成四段路線：什麼是 data stream、RxJS 為什麼有價值、怎麼接進元件、離開這個房間後怎麼在 production 用。

AI 補充他的身分決定了這場 talk 的可信度來源：在 Travix 用 React + RxJS 上線，所以講的不是玩具。值得注意的是他一開始就把「呈現層是誰」設定成不重要的變數——React、Vue 都行——這個設定在後半段會變成一個實際可驗證的主張（同一份邏輯，只換 import 的套件名）。

2. data stream 與 marble diagram 1:56–3:52

引用 André Staltz 的定義：reactive programmingi 就是用非同步 data streami 寫程式。凡是能對時間軸畫出來的東西都是 stream，他用「這個房間裡的人數」當例子：100 → 朋友離場變 99 → 回來又變 100。RxJS 社群用 marble diagrami 這種 ASCII 時間軸來畫：字母是發出的值、X 是錯誤、豎線是 stream 結束，而且時間只會往前。

推理因為要讓「stream」從抽象詞變成可操作的東西，作者先借 André Staltz 的定義收斂範圍——reactive programming 就是用非同步 data stream 寫程式——再用現場就能驗證的例子撐開它：這個房間裡的人數。100 個人，朋友離場變 99，回來又變 100。凡是能對著時間軸畫出來的東西都是 stream。有了直覺還不夠，還需要一套共同記號，所以他引入 RxJS 社群的 marble diagram：字母是發出的值、X 是錯誤、豎線是結束、箭頭是只能往前的時間軸。

• CMarble diagram：字母是值、X 是錯誤、豎線是結束，官方文件的通用語言→ 畫地圖
• E現場人數 100 人，朋友離場變 99，回來又變 100——就是一條 stream→ 存＋演練

AI 補充marble diagram 不只是教學插圖，它是 RxJS 世界的真正通用語：官方文件每個 operator 都用它、測試框架甚至能直接把 ASCII 的 marble 字串當成測試輸入（marble testing）。所以這一段看似在講比喻，其實是在教你之後查文件的閱讀能力。另外請留意圖上那條豎線：作者說「stream 很可能永遠不結束」——會不會結束是後面判斷「要不要取消訂閱」的關鍵，畫面上這條線在不在，決定了你要不要自己收尾。

3. Observable：和 Promise 差在哪 3:52–5:27

要把 marble diagram 寫成程式就需要 Observablei——一個正在 TC39i 標準化的 JavaScript 新型別。和 Promisei 逐條對照：Promise 只 resolve/reject 一次就結束，Observable 可以隨時間發出 0 到多個值、可以永不結束；Observable 是 lazy 的，沒 subscribe 就什麼都不發生，Promise 一建立就 eager 執行；最關鍵的是 Observable 可以取消，Promise 不行——元件已經 unmount 但請求還在跑，就是這個差別在救你。

推理因為聽眾手上已經有一個處理非同步的工具（現場問「誰知道 Promise」時全場舉手），作者選擇用對照來定義 Observable，而不是從零解釋。投影片列出五點：它是 JavaScript 的新型別、用來描述 push-based 的資料來源、可以持續發出多個值、是 lazy 的、可以被取消、而且是可組合的。對照 Promise 就清楚了：Promise 只 resolve 或 reject 一次就結束，Observable 可以發 0 到多個值甚至永不結束；Promise 一建立就開始跑，Observable 沒人 subscribe 就什麼都不做；最關鍵的是 Promise 取消不了，Observable 可以——他當場給的場景是「請求還在飛，元件卻已經 unmount 了」。

• CObservable：push-based、lazy、可發 0 到多值、可取消，subscribe 才啟動→ 畫地圖
• AObservable 在 subscribe 才啟動，就像函式定義了不會自己跑，要呼叫才執行→ 批判類比
• Rpush-based 與 pull-based 的分別→ 存＋回想

AI 補充「lazy」與「可取消」其實是同一件事的兩面：因為工作是在 subscribe 那一刻才啟動，這份工作才有一個明確的擁有者（subscription），也才有東西可以被取消。Promise 沒有這個擁有者，它一出生就在跑，所以 AbortController 得另外從外面補一個取消通道進去。投影片上還有一個講者沒展開的詞：push-based。它是指值由來源主動推給你，對照的是你主動去要的 pull-based（例如 iterator、async iterator）——這個分類決定了背壓（誰控制速度）要由誰負責。

4. Observable 的程式長相與 subscribe 5:27–7:02

假設瀏覽器已原生支援，new Observable(observeri => …) 裡的函式拿到 observer 物件：observable 是「可以被訂閱、拿值的東西」，observer 是「產生值的東西」，而且值只能在 constructor 內產生，外面的人動不了。observer 有三個方法：next 發值、error 送錯誤、complete 結束。社群慣例是變數名結尾加 $ 提醒自己這是 stream。subscribei 時對應傳三個 handler：值、錯誤、完成（完成最多只會觸發一次）。

推理因為要回答「值從哪來」，作者把 constructor 攤開：new Observable(function (observer) { … })，傳進去的函式拿到一個 observer 物件，值就是在這裡面用 observer.next(1)、next(2)、next(3) 推出去的，需要報錯就 observer.error()，要收尾就 observer.complete()。他順手切開兩個常被混用的名詞：observable 是「可以被訂閱、拿到值的那一端」，observer 是「產生值的那一端」。他也強調一個限制——值只能在 constructor 裡產生，外面的人插不進來。收值端則是 subscribe，依序傳三個 handler：值、錯誤、完成，其中完成最多只會觸發一次。最後補上社群慣例：變數名結尾加 $ 提醒自己這是 stream。

• R$ 結尾命名慣例→ 存＋回想

AI 補充請記住「值只能在 constructor 裡產生」這個限制，它不是實作細節而是刻意的封裝：因為外面動不了，Observable 才能保證每次 subscribe 都重跑同一份說明書。這個限制稍後會變成一個真實的障礙——UI 事件是從外面來的。另外投影片上被註解掉的那行 observer.error('oh crap') 值得留意：next 可以叫很多次，但 error 和 complete 只要叫了一次，這條 stream 就終止，之後的 next 一律被丟棄。這也是為什麼 subscribe 的第二、第三個 handler 天生互斥。

術語:$ suffix conventioni

5. RxJS 是什麼：Rx 的三類 API 7:02–8:52

Observable 目前還不能直接用，所以要靠實作：zen-observable 是 TC39 提案的最小實作，RxJSi 5 以上則是貼近提案又遠不止於此的完整版。Rx = Reactive Extensions，是跨平台的（.NET、Java 都有），RxJS 是它的 JavaScript 版。RxJS 給的東西分三類：建立 stream（constructor、interval、Node 風格 callback…）、合併 stream（merge、concat，把多條併成一條再 subscribe 一次）、以及 operatori（map、filter、reduce 這些函數式工具，只是現在作用在非同步的 stream 上）。

推理因為上一段的 new Observable 其實還不能在瀏覽器直接用，作者先交代實作選項：zen-observable 是 TC39 提案的最小實作，RxJS 5 以上則貼近提案但遠不止於此。接著他退一步解釋名字：Rx = Reactive Extensions，是一套跨平台的概念，.NET、Java 都有，RxJS 只是它的 JavaScript 版本。然後把 RxJS 提供的東西整理成三類：建立 stream（constructor、interval、Node 風格 callback…）、合併 stream（merge、concat，把多條併成一條之後只要 subscribe 一次）、以及 operator——如果你熟悉 map / filter / reduce，同一組工具現在作用在非同步的 stream 上。

• COperator：宣告以後進來的值怎麼處理，跟陣列方法同組但等 subscribe 才執行→ 畫地圖
• ARxJS operator 像陣列的 map/filter，但要等 subscribe 才真的執行→ 批判類比

AI 補充「多條併成一條再 subscribe 一次」這句話值得停一下：它是 RxJS 相對於回呼地獄的主要優勢——原本散在各處的多個非同步來源，可以先在宣告層合併成單一條 stream，錯誤處理與取消也就只需要做一次，而不是每個 callback 各做一份。至於 operator 與陣列方法的類比很好用但有一個重要差別：陣列的 map 立刻算完，stream 的 map 只是宣告「以後每個進來的值都這樣處理」，真正執行要等到 subscribe。

術語:Rx (Reactive Extensions)i

6. 前端為什麼需要它 8:52–10:24

三個前端天天遇到的場景：即時應用（WebSocket 訊息一直進來，要不重整頁面就更新畫面）、取消i（元件已 unmount 但請求還在飛，subscription 一結束就沒有 side effect 了）、離線與重試（斷線後要一直嘗試重連、回來再重抓，這種 retryi 邏輯可以宣告一次就交給 RxJS 跑）。他形容這是「心安」——邏輯集中在一個地方宣告，不用散在各處。

推理因為抽象的好處說服不了人，作者換成三個前端天天遇到的場景。第一是即時應用：WebSocket 訊息不斷進來，畫面要在不重整的情況下反應。第二是取消：元件已經因為使用者切走而 unmount，但它發出的請求還在飛——上一段提到的「subscribe 才啟動、可以取消」在這裡兌現，訂閱一結束就不再有 side effect。第三是離線與重試：斷線後要持續嘗試重連、回來後重新抓資料，這種 retry 邏輯可以在一個地方宣告一次，交給 RxJS 執行。他用「心安」來形容這種把邏輯集中宣告的感覺。

• RCancellation 與 Retry 這兩種真實場景的共通點→ 存＋回想

AI 補充這三個場景其實是同一件事的三種面貌：它們都不是「拿到一個值」，而是「一段延續中的關係」。Promise 天生描述前者，所以遇到後者就得靠額外的旗標、計數器與清理函式；Observable 因為本身就有結束與取消的概念，這些狀態才有地方放。作者這裡也悄悄示範了宣告式的價值——retry(5) 這種寫法把「重試策略」變成程式碼裡一個看得見的名詞，而不是散落在 catch 區塊裡的控制流程。

7. operator 實例與 pipe：順便瘦身 bundle 10:24–12:31

用 1~5 這條非同步數字流示範：先 filter 只留奇數得到 1、3、5，再 map 乘以 10 得到 10、30、50——和陣列的 filter/map 一樣，只是對象是 stream。程式面用 RxJS 5.5 引入的 pipei：不再一次載入全部 operator，只 import 用得到的函式，bundle 可以從幾百 KB 掉到三四 KB。pipe 接受一串 operator 函式，subscribe 最後那條結果流即可。

推理因為 operator 需要看得到才算懂，作者把它畫進上一段建立的 marble diagram 記號裡：一條 numbers 流是 1、2、3、4、5，套上 filter(n => n % 2 === 1) 得到 1、3、5，再套 map(n => n * 10) 得到 10、30、50，三條時間軸上下疊著看，operator 就是「stream 進、stream 出」。程式面他用 RxJS 5.5 引入的 pipe：從 rxjs/operators 只 import 用得到的 filter 與 map，串進 numbers$.pipe(…)，最後 subscribe 結果流。他強調這帶來的附加好處是打包體積——不再把整包 operator 拉進 bundle。

• CPipe：把要用的 operator 一個個 import 串起來，換來打包時能 tree shaking→ 畫地圖
• Enumbers$ 經 filter(奇數) 得 1,3,5，再 map(×10) 得 10,30,50→ 存＋演練

AI 補充pipe 的意義比「語法比較好看」更深：舊寫法是把 operator 掛在 Observable.prototype 上（numbers$.filter(...)），因此必須先 import 有副作用的 patch 檔，打包工具無從判斷哪些用得到；改成獨立函式後，未使用的 operator 才可能被 tree shakingi 移除。順帶一提，投影片上 filter 的條件寫 n % 2 === 1 只對正數成立——負奇數的餘數是 -1——這在示範裡無所謂，但搬進真實程式時要小心。

8. Subject：讓外部把值送進 stream 12:31–14:03

前面的 Observable 有個限制：值只能在 constructor 裡產生，外面送不進去。但按鈕元件就是要把事件往回送、讓 stream 發出新值再當 props 流回來，形成單向循環。Subjecti 就是解法：它同時實作了 Observable 和 Observer，所以既有 subscribe，也有 next／error／complete。範例裡先 subscribe，再從外面呼叫三次 next，console 就依序印出 1、2、3；沒有 complete，它就一直等著下一個值。

推理因為那個限制在 UI 上會立刻卡住——按鈕被點、輸入框被打字，這些值天生來自外部——作者引入 Subject 來補洞。他先畫出需要的形狀：observable 把 props 給元件，元件把事件送回來，形成一個循環；能同時做這兩件事的東西就是 Subject。定義很乾脆：Subject 同時是 Observable 也是 Observer，所以它既有 subscribe，也有 next / error / complete。程式示範是先 new Subject()、先 subscribe（此時還是空的 stream），再從外面連叫三次 next(1)、next(2)、next(3)，console 依序印出 1、2、3；因為沒有 complete，它就一直開著等下一個值。投影片同時列出 BehaviorSubjecti：帶初始值的 Subject。

• CSubject：同時是 Observable 也是 Observer，事件世界送值進 stream 的入口→ 畫地圖
• CBehaviorSubject：記得最後一個值，新訂閱者一接上就先拿到當前狀態→ 畫地圖
• E先 new Subject() 再 subscribe，之後才 next(1)(2)(3)，依序印出 1、2、3→ 存＋演練

AI 補充「先 subscribe 再 next」的順序不是巧合，而是必要的：一般的 Subject 不保存歷史，訂閱之前發出的值就永遠錯過了。這正是投影片上 BehaviorSubject 存在的理由——它記得最後一個值，新訂閱者一接上就先拿到當前狀態，這在 UI 上幾乎總是你要的（元件掛載時就該看到現在的值，而不是等下一次變化）。作者沒有展開，但這個差別是實務上最常見的 Subject 選型錯誤。

9. 把 props 當成 stream 14:03–17:12

轉到 component 層。他刻意用兩套 rendering library：React、Vue、Preact 都只是呈現層，邏輯應該全留在 RxJS 這一側。這些函式庫本來就是反應式的——收到新 propsi 就重繪——所以只要把 props 想成一條 stream，元件就能永遠是 stateless。單向是 observable → 元件；要接住 click、input 這些事件就再加 Subject：使用者打字 → handler 把值送進 Subject → Subject 非同步處理後把新 props 送回元件，變成受控輸入i。連「打字時去伺服器檢查是否重複」這種非同步驗證錯誤，也能一起串成 props 流回去。

推理因為要接的是元件，作者先說明為什麼他刻意同時用 React 和 Vue：這些函式庫只是呈現層，邏輯應該全留在 RxJS 那側，所以哪一套並不重要。他接著點出一個關鍵觀察——這些函式庫本來就是反應式的：收到新 props 就重繪。那麼只要把 props 想成一條 stream，元件就可以永遠 stateless。投影片先畫單向：RxJS 的 Observable 把 props 推給 React 元件。但單向不夠，click、input 這些事件要能回來，於是把左邊換成 Subject：使用者在輸入框打字 → handleChange() 把值送回 Subject → Subject 非同步處理後把 inputValue 當 props 送回元件，形成受控輸入。他還補了一個延伸：打字時去伺服器檢查是否重複這種非同步驗證，錯誤訊息也能一起串成 props 流回去。

• CStateless component：狀態不住在元件裡，元件只是 stream 的最後一個訂閱者→ 畫地圖
• A把 props 當 stream 之後，元件變得像純函式：同樣輸入永遠同樣輸出→ 批判類比
• R受控輸入的完整迴路→ 存＋回想

AI 補充這一段是整場的樞紐，值得把它翻譯成一句話：狀態不再住在元件裡，而是住在 stream 裡，元件只是這條 stream 的最後一個訂閱者。這麼做的直接後果是元件變成純函式——同樣的 props 永遠畫出同樣的畫面，測試時不必模擬生命週期。第二張圖的三條箭頭也是刻意的：inputValue 下去、handleChange 上來、inputValue 再下去——它畫的正是「受控輸入」的完整迴路，值繞了一圈才回到畫面，所以中間才有位置插入 debounce、驗證這些非同步處理。

術語:Stateless componenti

10. interval 範例，與今天手接的痛 17:12–19:45

具體做一次：intervali(1000) 每秒吐一個遞增整數，但元件要的是 props 物件，所以用 map 把 n 轉成 { interval: n }，prop stream 就成形了。問題出在「接」這一段——用今天的 React/Vue 寫法，你得先宣告 internal state、在 mount 時 subscribe、在值進來時 setState、render 再讀 state，最後還要在 unmount 時取消訂閱以免記憶體洩漏i。他直說：要記的事太多了。

推理因為要具體，作者選了最小的例子：一個接收 interval prop、每秒加一的元件。產生 stream 這半很短——interval(1000) 每秒吐一個遞增整數，但元件要的是物件，所以 pipe 一個 map(n => ({ interval: n })) 把它轉成 { interval: 1 }、{ interval: 2 }…，props$ 就成形了。真正的問題出在「接」這半：他把 React 與 Vue 的寫法並排放上螢幕——宣告 state、在 componentDidMount / beforeMount 裡 subscribe、在值進來時 setState、render 讀 state、最後在 componentWillUnmount / beforeDestroy 裡 unsubscribe 以免記憶體洩漏。兩側都是整整一屏。他的評語很直接：要記的事太多了。

• CSubscription：訂閱 Observable 產生的物件，忘了取消永不結束的 stream 就洩漏→ 畫地圖
• EReact 與 Vue 並排的 interval 元件樣板，語法不同但形狀一模一樣、都整整一屏→ 存＋演練
• P檢查自己專案有沒有訂閱了永不結束的 stream 卻忘記取消→ 練習

AI 補充這張並排投影片是整場最有說服力的一張，因為它讓「痛」變成可以用眼睛測量的東西：左右兩邊的差異只有語法，樣板的形狀一模一樣——這正暗示了它可以被抽出來。值得一提的是最後那個 unsubscribe：它不是最佳實踐建議，而是必要動作。interval 是永不結束的 stream（回到第 2 段那條沒有豎線的時間軸），元件消失後它仍然每秒推值、仍然抓著 setState 的參照，記憶體洩漏就是這樣來的。

術語:Subscriptioni

11. 理想的接法、三個好處，與既有方案的限制 19:45–22:49

他要的是：左邊 stateless 元件、右邊 prop stream，中間一個 higher-order componenti 把兩者接起來，其他都別讓我知道。這樣換來三個好處：程式碼變得函數式、由上往下讀就懂；邏輯與呈現徹底分離，行為都留在 RxJS 那側；元件無狀態因此好測試。既有方案 redux-observablei、recycle、vuerx、vue-streams 他都用過，但兩個限制沒解決：走 Redux 等於把自己綁在一個全應用的 store 上，而他只想要「一條 stream 加一個元件」；而且多數方案只能產生新的 observable 往下傳，沒辦法把父層傳進來的 props 也當成 stream 接住。

推理因為形狀固定，作者直接畫出他要的介面：左邊一個 stateless 元件、右邊一條 props$，中間一個 higher-order component 把兩者接起來，寫成一行 link(props$)(Interval)，其他都別讓我知道。他接著說明這樣換來三個好處：程式碼變得函數式、由上往下讀就懂，不必在內部狀態之間來回追；邏輯與呈現徹底分離，行為全留在 RxJS 那側；元件無狀態，因此容易測試。然後他誠實地檢視既有方案——redux-observable（用 epici 把 dispatch 的 action 當成 stream 處理）、recycle、vuerx、vue-streams——他都用過，但有兩個限制沒被解決：走 Redux 等於把自己綁在一個全應用的 store 上，而他要的只是「一條 stream 加一個元件」；而且多數方案只能往下產生新的 observable，沒辦法把父層傳進來的 props 也當成 stream 接住。

• CHigher-order component：把 props$ 跟 stateless 元件接起來的中間層，寫成一行→ 畫地圖
• Rredux-observable 為什麼不符合作者的需求→ 存＋回想

AI 補充請注意這兩個限制不是抱怨，而是規格書：它們正好定義了下一段那個工具必須做到什麼。第二個限制尤其關鍵，值得翻成具體場景——如果上游 props 不是 stream，那麼「prop 變了要取消前一個請求」這件事就只能回到生命週期比對舊值新值，也就回到了上一段那堆樣板。至於第一個限制，它其實是「元件層級的狀態」與「應用層級的狀態」之爭：Redux 假設你想要後者，而作者主張很多時候你只需要前者。

12. proppy：attach、withObservable、withStream 22:49–25:42

他的解法：withObservable 把來源 observable 轉成 props，attach 這個 HOC 把 composition 接到 stateless 元件上。左右兩份程式碼唯一的差別是 import 的套件名（proppyi-react vs proppy-vue）。再進一步是 withStreami：它讓你把「傳進來的 props」當成 stream 收，再回傳一條新的 stream——路由參數 product ID 從 1 變成 2 時，可以取消前一個請求、直接發新的，新 props 立刻流回元件。此外也顧到 SSR（先在伺服器端把 static props 算好再輸出 HTML）與全應用設定（API endpoint、主題，甚至 Redux store 都能當成一個 composition 取用）。

推理因為規格已經明確，作者直接給出他的實作 proppy。第一層對應「能接」：withObservable 把來源 observable 轉成 props，attach 這個 HOC 把這份 composition 接到 stateless 元件上。他請大家找出左右兩邊的差異——只有 import 的套件名不同（proppy-react vs proppy-vue），這是他前面「呈現層可以互換」主張的直接證據。第二層對應「能接住上游」：proppy-rx 的 withStream 讓你把 incomingProps$ 當成 stream 收進來、再回傳一條新的 props$，也就是投影片標題那句 stream in => stream out。他用路由參數舉例：product ID 從 1 變成 2 時，可以取消前一個請求、直接發新的，新 props 立刻流回元件。最後補兩個實務缺口：SSR（先在伺服器端把 static props 算好再輸出 HTML）與全應用設定（API endpoint、主題，甚至 Redux store 都能當成一個 composition 取用）。

• CwithStream：stream in、stream out，把上游 props 也當 stream 接住再送出新的→ 畫地圖
• Eproppy-react 換成 proppy-vue，程式碼唯一差異只有 import 的套件名→ 存＋演練
• R全面 stream 化之後 SSR 為什麼變麻煩→ 存＋回想

AI 補充值得指出的是，最後那個「Redux store 也能當成 composition」其實回應了上一段對 Redux 的批評——他不是反對全域 store，而是反對被強迫接受它；在這個設計裡全域 store 只是眾多來源的一種。另外 SSR 那段是誠實的：全面 stream 化之後，伺服器端渲染i確實會變麻煩，因為 HTML 必須在某個時間點定格，而 stream 沒有天然的定格點——所以才需要一個專門的機制先把 static props 算完。這是採用這套做法前最該先確認的一項成本。

13. 結語：先有 use case 再用 Rx 25:42–26:44

收尾很誠實：Rx 很重、學習曲線很陡，不要因為別人在用就用。真的被非同步資料流折磨時，它會讓困難的事變得非常容易；但沒想清楚就用，它也會讓簡單的事變得很難。

推理因為前面花了二十幾分鐘證明「可以做到」，作者在最後刻意拉回「該不該做」。他的回答沒有迴避成本：Rx 很重、學習曲線很陡，不要因為別人在用就用。判準是有沒有真實的使用情境——如果你真的在跟非同步資料流搏鬥，它會讓困難的事變得非常容易；但沒想清楚就用，它也會讓簡單的事變得很難。

• P用三個問題檢查自己的元件是不是真的需要 RxJS→ 練習

AI 補充這句忠告可以直接翻成一組檢查清單：你的畫面是否需要合併多個非同步來源？是否需要在事件之間取消先前的工作？是否有 debounce、retry、重播這類時間相關的需求？三題都答不出來，那麼 useState 加 fetch 就夠了。反過來說，一旦你發現自己在手寫「這個請求過期了要忽略」「這個訂閱要記得清掉」的旗標，那就是 stream 已經在你的程式裡了，只是還沒有名字。