我一直在閱讀有關傳說，他們的意圖和他們的用法。但是 - 我有兩個問題，我真的想要關閉一些，然後是更多的意見問題。Redux saga，rx-observable。隨着香草取電話，爲什麼需要通過thunk？
我讀了一些使用能夠動態生成Sagas的模式來減少樣板的博客 - 但是你不能用Thunk來做到嗎？此外，任何例子都會很棒。
的終極版，驟降與終極版，觀測任何意見？
謝謝！
免責聲明：我是終極版，可觀察到的作者之一，所以我的兩個終極版，傳奇和終極版，可觀察到的意見沾染了偏置
由於您使用的術語佐賀（而不是史詩）我會假設你在減少事件的情況下（而不是可觀察到的）。
在最簡單的情況下，一個AJAX請求，實際上並不直接在你的發生器傳奇內部處理。相反，您使用的幫助程序正在創建簡單的舊JavaScript對象，其中代表效果意圖，您yield，然後redux傳奇中間件本身在內部執行的效果，隱藏你，提供結果回到你的收益率，如yourSaga.next(response)。
有些人喜歡這樣，因爲你的英雄傳奇發電機真的是純粹的。因爲它使用生成器來支持多種效果，所以它可以很容易地進行測試而不會模仿，因爲您只是斷言它會產生效果。就我個人而言，我在實踐中發現這看起來比實際上涼得多：很多時候你最終都會有效地重現傳奇在你的測試中所做的一切。你現在正在測試執行的傳奇是否正確，沒有測試行爲的傳奇故事。許多人不在乎（甚至沒有注意到這一點），但我做到了。我想有些人甚至更喜歡它。這被稱爲「作爲數據的效果」。 FWIW，redux-observable不使用這種「效果作爲數據」模型，這是它和REDX傳奇之間最根本的區別。
將它們與它們與復原thunk進行比較時，最大的區別是：基於時間的操作（例如，反彈連續操作）在單獨使用redux-thunk時不實用，沒有大的黑客攻擊。說到反彈，它並沒有配備任何公用設施，所以你處理的是處理反彈和其他常見效果。測試要困難得多。
但是，這些主要是意見。當然，非常成功的應用程序可以（並且）使用redux-thunk。想起了https://m.twitter.com。
我認爲這不會引起爭議，認爲redux-thunk顯然更容易學習和使用簡單的請求 - >響應AJAX調用，而不需要取消等。事實上，我經常建議不熟悉RxJS的用戶對簡單的東西使用redux-thunk，並且只對更復雜的東西依賴於redux-observable，這樣他們可以保持高效並隨時學習。絕對有學術「正確性」和美麗的代碼的地方，但對於大多數人的工作，shipit™應該是第一優先。用戶不關心我們的代碼是多麼正確，只是它存在和[大多數]是有效的。
關於對終極版，傳奇與終極版，可觀察到的意見，我有偏見，因爲我是終極版，可觀察到的作者之一，但我總結了一些我的想法在以前的一個SO帖子：Why use Redux-Observable over Redux-Saga?他們有一個相似的總體模式，但是redux-saga使用「效果作爲數據」，而可觀察到的reduce使用RxJS的實際效果。兩者的優點和缺點，主要使用RxJS的專業人員，認爲它是一種非常有用的技能，可用於除了可觀察到的事物以外的其他事物，並且幾乎可以肯定會超過可觀察到的事件/稀有事件，因此該技能具有高度的可轉換性。