RxJS/Cycle.js 與 React/Vue 相比更適用于什么樣的應用場景？

RxJS/Cycle.js 與 React/Vue 相比更適用于什么樣的應用場景？ - 知乎 https://www.zhihu.com/question/40195289

?

實際項目中，React, Vue 等就很方便了。而使用 Rxjs, Cycle.js 會引入大量的函數(shù)式概念，無法輕松融入現(xiàn)有項目。
對于全新前端項目來說，要完全投入 Cycle.js 的懷抱也總有大炮打蚊子的感覺，畢竟前端項目充滿了各種狀態(tài)，變量，副作用。快速迭代時，為了臨時業(yè)務需要，也會容忍一些反模式的代碼出現(xiàn)。
那么對于前端項目來說，Rxjs，Cycle.js 更適用于何種場景呢？

某前輩同事的原話：
這個 app 還沒復雜到需要讓我忍受
action$.startWith( 0 ).scan( ( x, y ) => x + y )

這樣代碼的程度。

［其實個人感覺這樣的代碼含蠻帶感的哎（ 是我 2 young, 2 simple 么），畢竟看起來高大上，會讓那些只會jq的童鞋完全搞不懂 ^_^ （神馬心態(tài)） ］ 尤雨溪 前端開發(fā)、JavaScript、前端工程師 話題的優(yōu)秀回答者 100 人贊同了該回答 先說觀點，React/Vue 和 Cycle 一起用是不太合理的，因為 Cycle 本身定位是框架，定義了整個應用的代碼組織方式和開發(fā)范式，那就是無論是用戶事件處理還是服務端數(shù)據(jù)同步，統(tǒng)統(tǒng)用 Rx 來做，Cycle 自己也提供了偏好的 view layer（基于 virtual-dom 的 DOM driver）。總的來說 Cycle 的范式侵入性很強，屬于要么不用要用就得全盤接受 Rx for everything 的理念。我本身對于這個理念持保留態(tài)度，同時目前還沒有看到過大型 Cycle 應用的例子，那么自然對于 Cycle 到底好不好用，也是持保留態(tài)度。 ?另一方面，在 React/Vue 應用中部分使用 Rx 是完全沒有問題的。思路上來說就是把 React/Vue 組件的 local state 當做一個『中介』，在一個 Rx Observable 的 subscribe 回調(diào)里面更新組件狀態(tài)。通過簡單的綁定庫支持，可以完全把 component state 作為一個實現(xiàn)細節(jié)封裝掉，實現(xiàn) Observable -> view 的聲明式綁定。參考： ?- Vue + Rx: https://github.com/vuejs/vue-rx/ - React + Rx: GitHub - belfz/fully-reactive-react-example ?我個人傾向于在適合 Rx 的地方用 Rx，但是不強求 Rx for everything。比較合適的例子就是比如多個服務端實時消息流，通過 Rx 進行高階處理，最后到 view 層就是很清晰的一個 Observable，但是 view 層本身處理用戶事件依然可以沿用現(xiàn)有的范式。 ?--- ?題外話， ?@沈嶸 ?的答案拿 Vue 說事，然后說不可避免會遇到『性能墻』問題，而 Virtual DOM 是 React 對『性能墻』的解決方案，我只能說這個看法基本屬于對 Virtual DOM 理解停留在宣傳層面的水平。詳見 網(wǎng)上都說操作真實 DOM 慢，但測試結(jié)果卻比 React 更快，為什么？ - 尤雨溪的回答。 ?而關(guān)于『復雜度墻』，則要么是對『單向數(shù)據(jù)流』的理解停留在宣傳層面，要么是對 Vue 的了解有限（不了解您可以少說兩句）。React 如果沒有 Flux，其實也是依賴 component local state。React + Redux 做的事情說到底就是把應用狀態(tài)從組件本身隔離出去統(tǒng)一管理，這種思路并不是只有 React 能做到，只要有個聲明式的視圖層就行了。這也是為什么 Redux 是 view-layer agnostic，Vue，Angular 2 都有配合 Redux 使用的例子，Vue 自己也有專屬的狀態(tài)管理方案 Vuex。（這些話我其實在知乎重復過好幾遍了，只是太多人被 FB 的宣傳洗了腦，說 React 必提 virtual dom 性能好 + 單向數(shù)據(jù)流應對復雜度，對其本質(zhì)卻不知其所以然...） 編輯于 2016-11-07 100 11 條評論 分享 收藏收起 ?魯小夫 前端開發(fā)、JavaScript 話題的優(yōu)秀回答者 還好吧，我覺得 event stream 比 imperative style 可讀多了 發(fā)布于 2016-02-07 0 添加評論 分享 收藏 ?米嘉 怪獸工程師 15 人贊同了該回答 RxJS/Cycle.js解決的是數(shù)據(jù)流的問題，為什么有數(shù)據(jù)流的問題，是因為更傾向于或者受限于使用單向數(shù)據(jù)綁定，核心其實解決的是State管理的問題。偏向于Redux或者Flux架構(gòu)會有全局State的困擾，而最近Redux作者也在新的文章中寫到“Local State is Fine”， https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.m8dop3xqq 我們廠（小廠）在iOS（Native）、Android（ReactNative）和Web上都選擇了Data Flow驅(qū)動的設(shè)定思路，使用RxJS（RxSwift）來作為Data Flow驅(qū)動的核心組件，架構(gòu)基本類似，把全局狀態(tài)和組件局部狀態(tài)分開，結(jié)構(gòu)很清楚，因為Data Flow會讓你比較容易追蹤到數(shù)據(jù)變化的原因，最終導致UI變化的原因。其實只要把全局狀態(tài)和局部狀態(tài)有效管理，使用Redux也很好，不過使用RxJS是因為我們可以很輕松的把全局狀態(tài)Stream和組件局部狀態(tài)的Stream通過Rx運算子共同運算，代碼會更加清晰，同時大大減少對全局狀態(tài)的污染，有效控制數(shù)據(jù)狀態(tài)變化傳播的范圍。 Reactive programming is oriented around data flows and the propagation of change. Erik Meijer gave us Rx because he was induced by push-based systems. When you want to stay up to date about the state of the world, it is much better to push instead of to pull. Observable Stream + FRP圍繞數(shù)據(jù)流驅(qū)動設(shè)計App架構(gòu)，會大大減少UI上的復雜度，非常看好的結(jié)構(gòu)方向。 ?而React本身定義了數(shù)據(jù)流向的要求，但是沒有定義如何解決這個問題，所以，React和RxJS解決的不是一個問題…… They have not solved the problem of how to achieve explicit data-flow graphs https://medium.com/@fkrautwald/plug-and-play-all-your-observable-streams-with-cycle-js-e543fc287872#.zcbj1db3x 發(fā)布于 2016-09-28 15 添加評論 分享 收藏 ?Wang Namelos 宇宙級React開發(fā) 2 人贊同了該回答 我只能說Cycle是大炮，但是打蚊子一點不麻煩。就說打包比React小，本身Observable就是stage-1提案，有一天標準發(fā)布Cycle體積幾乎就只有Virtual DOM了。 部分引入Rx只會獲得部分收益，總要從Observable這個monad容器出來進去，導致編碼本身大量冗余，丟掉大部分FP的好處。 用用Cycle你就能發(fā)現(xiàn)比React大量的手動綁定簡潔多了，這樣重構(gòu)也方便。Cycle效率真心遠超React Redux，這取決于React onClick綁定，導致要做到類似Reactive Programming的效果（Flux / Redux 對React來說是標配），需要做大量重復工作，Flux只是模式，導致不能真的抽象成庫。這是React為數(shù)不多的硬傷。 缺點就是Rx4測試困難，如果你們不要求覆蓋率，調(diào)試Rx其實并不是很麻煩的事情。 發(fā)布于 2016-03-14 2 添加評論 分享 收藏 ?沈嶸 產(chǎn)品總監(jiān) 22 人贊同了該回答 Vue 的年齡輕，但是 Vue 卻是最傳統(tǒng)的基于 observer 的MVC，但是做到了盡量簡單。但是不可避免的，當你的 Web App 越來越復雜，自然也會撞到兩堵墻，"性能墻"和"復雜度墻"（否則也就不會有React, Cycle.js..., Angular早就一統(tǒng)江湖了）。 ?React 針對"性能墻"的方案就是 VirtualDOM，對于"復雜度墻"的方案就是單向數(shù)據(jù)流，希望用一些"函數(shù)式"的概念來規(guī)避過于復雜的狀態(tài)維護（對于稍微復雜一些的應用，這是一定會出現(xiàn)的問題）。但是由于 React 自身不是"函數(shù)式"的，又有大量的工程妥協(xié)，因此真的是充滿了 boilerplate。 ?Cycle.js 其實是 FRP 在 Web App 領(lǐng)域的一種"模式"（Source/Driver, MVI），是天生用來對付"復雜度墻"的。而且，得益于 React 的思路, Cycle.js 也老大不客氣地把 VirtualDOM 拿來緩解"性能墻"問題。 ?但是，由于 Cycle.js 尚沒有被大量的開發(fā)者使用，缺少工程驗證，尤其是性能評估方面；而且也沒有大廠持續(xù)地投資，所以還是在探索階段。不過以我個人體驗來看，Cycle.js 是一種“對”的開發(fā)方式。 ?看 Doc 和 Tutorial 真是很精彩，作者是反應式編程的鐵桿粉絲，自己也造了諸如 xstream 這樣的輪子，HCI 的理念很不錯，但是能用好它的開發(fā)者應該不多，強制全盤在 Reactive 的閉環(huán)內(nèi)進行編程，沒有非常優(yōu)秀的 FRP 基礎(chǔ)很難在狀態(tài)規(guī)模變得十分龐大的情況下理清各個事件流之間的關(guān)系。它可以加深你對 FRP 的理解，但我不認為它適用于去做真正的項目，你的團隊就沒有這個能力去全盤使用它。 尤雨溪 前端開發(fā)、JavaScript、前端工程師?話題的優(yōu)秀回答者 100 人贊同了該回答

先說觀點，React/Vue 和 Cycle 一起用是不太合理的，因為 Cycle 本身定位是框架，定義了整個應用的代碼組織方式和開發(fā)范式，那就是無論是用戶事件處理還是服務端數(shù)據(jù)同步，統(tǒng)統(tǒng)用 Rx 來做，Cycle 自己也提供了偏好的 view layer（基于 virtual-dom 的 DOM driver）。總的來說 Cycle 的范式侵入性很強，屬于要么不用要用就得全盤接受 Rx for everything 的理念。我本身對于這個理念持保留態(tài)度，同時目前還沒有看到過大型 Cycle 應用的例子，那么自然對于 Cycle 到底好不好用，也是持保留態(tài)度。

另一方面，在 React/Vue 應用中部分使用 Rx 是完全沒有問題的。思路上來說就是把 React/Vue 組件的 local state 當做一個『中介』，在一個 Rx Observable 的 subscribe 回調(diào)里面更新組件狀態(tài)。通過簡單的綁定庫支持，可以完全把 component state 作為一個實現(xiàn)細節(jié)封裝掉，實現(xiàn) Observable -> view 的聲明式綁定。參考：

- Vue + Rx: https://github.com/vuejs/vue-rx/
- React + Rx: GitHub - belfz/fully-reactive-react-example

我個人傾向于在適合 Rx 的地方用 Rx，但是不強求 Rx for everything。比較合適的例子就是比如多個服務端實時消息流，通過 Rx 進行高階處理，最后到 view 層就是很清晰的一個 Observable，但是 view 層本身處理用戶事件依然可以沿用現(xiàn)有的范式。

---

題外話，

@沈嶸 的答案拿 Vue 說事，然后說不可避免會遇到『性能墻』問題，而 Virtual DOM 是 React 對『性能墻』的解決方案，我只能說這個看法基本屬于對 Virtual DOM 理解停留在宣傳層面的水平。詳見 網(wǎng)上都說操作真實 DOM 慢，但測試結(jié)果卻比 React 更快，為什么？ - 尤雨溪的回答。

?

而關(guān)于『復雜度墻』，則要么是對『單向數(shù)據(jù)流』的理解停留在宣傳層面，要么是對 Vue 的了解有限（不了解您可以少說兩句）。React 如果沒有 Flux，其實也是依賴 component local state。React + Redux 做的事情說到底就是把應用狀態(tài)從組件本身隔離出去統(tǒng)一管理，這種思路并不是只有 React 能做到，只要有個聲明式的視圖層就行了。這也是為什么 Redux 是 view-layer agnostic，Vue，Angular 2 都有配合 Redux 使用的例子，Vue 自己也有專屬的狀態(tài)管理方案 Vuex。（這些話我其實在知乎重復過好幾遍了，只是太多人被 FB 的宣傳洗了腦，說 React 必提 virtual dom 性能好 + 單向數(shù)據(jù)流應對復雜度，對其本質(zhì)卻不知其所以然...） 編輯于?2016-11-07 10011 條評論 分享 收藏收起 魯小夫 前端開發(fā)、JavaScript?話題的優(yōu)秀回答者 還好吧，我覺得 event stream 比 imperative style 可讀多了 發(fā)布于 2016-02-07 0添加評論 分享 收藏 米嘉 怪獸工程師 15 人贊同了該回答 RxJS/Cycle.js解決的是數(shù)據(jù)流的問題，為什么有數(shù)據(jù)流的問題，是因為更傾向于或者受限于使用單向數(shù)據(jù)綁定，核心其實解決的是State管理的問題。偏向于Redux或者Flux架構(gòu)會有全局State的困擾，而最近Redux作者也在新的文章中寫到“Local State is Fine”， https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.m8dop3xqq
我們廠（小廠）在iOS（Native）、Android（ReactNative）和Web上都選擇了Data Flow驅(qū)動的設(shè)定思路，使用RxJS（RxSwift）來作為Data Flow驅(qū)動的核心組件，架構(gòu)基本類似，把全局狀態(tài)和組件局部狀態(tài)分開，結(jié)構(gòu)很清楚，因為Data Flow會讓你比較容易追蹤到數(shù)據(jù)變化的原因，最終導致UI變化的原因。其實只要把全局狀態(tài)和局部狀態(tài)有效管理，使用Redux也很好，不過使用RxJS是因為我們可以很輕松的把全局狀態(tài)Stream和組件局部狀態(tài)的Stream通過Rx運算子共同運算，代碼會更加清晰，同時大大減少對全局狀態(tài)的污染，有效控制數(shù)據(jù)狀態(tài)變化傳播的范圍。
Reactive programming is oriented around data flows and the propagation of change. Erik Meijer gave us Rx because he was induced by push-based systems. When you want to stay up to date about the state of the world, it is much better to push instead of to pull.

Observable Stream + FRP圍繞數(shù)據(jù)流驅(qū)動設(shè)計App架構(gòu)，會大大減少UI上的復雜度，非常看好的結(jié)構(gòu)方向。

而React本身定義了數(shù)據(jù)流向的要求，但是沒有定義如何解決這個問題，所以，React和RxJS解決的不是一個問題……
They have not solved the problem of how to achieve explicit data-flow graphs
https://medium.com/@fkrautwald/plug-and-play-all-your-observable-streams-with-cycle-js-e543fc287872#.zcbj1db3x 發(fā)布于 2016-09-28 15添加評論 分享 收藏 Wang Namelos 宇宙級React開發(fā) 2 人贊同了該回答 我只能說Cycle是大炮，但是打蚊子一點不麻煩。就說打包比React小，本身Observable就是stage-1提案，有一天標準發(fā)布Cycle體積幾乎就只有Virtual DOM了。
部分引入Rx只會獲得部分收益，總要從Observable這個monad容器出來進去，導致編碼本身大量冗余，丟掉大部分FP的好處。
用用Cycle你就能發(fā)現(xiàn)比React大量的手動綁定簡潔多了，這樣重構(gòu)也方便。Cycle效率真心遠超React Redux，這取決于React onClick綁定，導致要做到類似Reactive Programming的效果（Flux / Redux 對React來說是標配），需要做大量重復工作，Flux只是模式，導致不能真的抽象成庫。這是React為數(shù)不多的硬傷。
缺點就是Rx4測試困難，如果你們不要求覆蓋率，調(diào)試Rx其實并不是很麻煩的事情。 發(fā)布于 2016-03-14 2添加評論 分享 收藏 沈嶸 產(chǎn)品總監(jiān) 22 人贊同了該回答

Vue 的年齡輕，但是 Vue 卻是最傳統(tǒng)的基于 observer 的MVC，但是做到了盡量簡單。但是不可避免的，當你的 Web App 越來越復雜，自然也會撞到兩堵墻，"性能墻"和"復雜度墻"（否則也就不會有React, Cycle.js..., Angular早就一統(tǒng)江湖了）。

React 針對"性能墻"的方案就是 VirtualDOM，對于"復雜度墻"的方案就是單向數(shù)據(jù)流，希望用一些"函數(shù)式"的概念來規(guī)避過于復雜的狀態(tài)維護（對于稍微復雜一些的應用，這是一定會出現(xiàn)的問題）。但是由于 React 自身不是"函數(shù)式"的，又有大量的工程妥協(xié)，因此真的是充滿了 boilerplate。

Cycle.js 其實是 FRP 在 Web App 領(lǐng)域的一種"模式"（Source/Driver, MVI），是天生用來對付"復雜度墻"的。而且，得益于 React 的思路, Cycle.js 也老大不客氣地把 VirtualDOM 拿來緩解"性能墻"問題。

但是，由于 Cycle.js 尚沒有被大量的開發(fā)者使用，缺少工程驗證，尤其是性能評估方面；而且也沒有大廠持續(xù)地投資，所以還是在探索階段。不過以我個人體驗來看，Cycle.js 是一種“對”的開發(fā)方式。 發(fā)布于 2016-02-08 2214 條評論 分享 收藏 Cyandev 大二學生，資深果粉，編程初學者 看 Doc 和 Tutorial 真是很精彩，作者是反應式編程的鐵桿粉絲，自己也造了諸如 xstream 這樣的輪子，HCI 的理念很不錯，但是能用好它的開發(fā)者應該不多，強制全盤在 Reactive 的閉環(huán)內(nèi)進行編程，沒有非常優(yōu)秀的 FRP 基礎(chǔ)很難在狀態(tài)規(guī)模變得十分龐大的情況下理清各個事件流之間的關(guān)系。它可以加深你對 FRP 的理解，但我不認為它適用于去做真正的項目，你的團隊就沒有這個能力去全盤使用它。 發(fā)布于 2016-11-12 0添加評論 分享 收藏 凌柏超 妹子 滾床單嗎 滾 1 人贊同了該回答 可惜很多人只會跟風大牛 reactive的確可以使代碼清晰些 希望大家多看看 發(fā)布于 2016-02-07 11 條評論 分享 收藏

轉(zhuǎn)載于:https://www.cnblogs.com/Unknw/p/6422111.html

總結(jié)

以上是生活随笔為你收集整理的RxJS/Cycle.js 与 React/Vue 相比更适用于什么样的应用场景？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。