如何看待文章<WHY REACT/REDUX IS AN INFERIOR PARADIGM>?

看 尤雨溪 的blog看到的.

文章在這裡 André Staltz


看完了,說得很好,指出來了 react + redux 的一些問題,主要集中在

1. redux 這套東西 boilerplate code 太多,噪音太多,加一個東西得在很多文件里加,action types 有點煩,switch case 綁定很煩

2. react jsx 語法噪音太多(類XML 語法 vs js字面量)

3. react 用到了很多 OOP 思想,fp 的 IO as functions" input and output 這一點沒有貫徹

作者提出來,就是要減少噪音,減少 boilerplate code,簡化勞動,fp化,說 react/ redux 是進步但不是終點,希望大家都去試試 Elm 和他的 Cycle.js。

這些觀點還是比較理智的,也確實存在這個情況。

就我而言,我也認為現在社區里最熱的 react + redux 有著一些冗餘,我同意他關於 redux 組織代碼比較麻煩這一點。

至於 jsx 和 js 字面量,我覺得 jsx 的冗餘程度還是可以接受的,一切都有 tradeoff,從可讀性上來講 jsx 算是比較合理的 tradeoff,不過正如 Jade vs HTML 這樣,personal taste。


同意JSX部分。

所以我也是用virtual-dom自製一個來用,不用react和redux。純js寫markup很好,不想寫html,尤其html里還不得不插一些js代碼,例如map和if等等。

自製還能假定所有組件都是pure的,然後默認的shouldUpdate實現只做淺比較,需要深比較也能加標記,還有其他一些和shouldUpdate相關的。雖然基於react包裝一個基類也可以實現,但80k(未壓縮)就能實現我要的功能,何必用個600幾k的。

=== update 2016-02-23 ===

說說redux,一開始覺得redux的理念挺好的,後來發現實現同樣的理念,只需要幾行代碼,於是就棄用它了,雖然還是繼續用action types、switch這套結構。今天發現,action types其實是不需要的,直接用一個函數表示一個action就可以了,不會遇到命名衝突問題,而且action可以分散在各個模塊里,不需要都放在一個地方,或者做二次分發,switch也不需要了。如果其他模塊需要使用action,就export然後import。

感覺就是把從redux里學到的概念都一個個丟棄最後只剩下一個,就是唯一的全局狀態。

替代了redux的store類的代碼:v3/base.js at master · reusee/v3 · GitHub

用例:v3/main.js at master · reusee/v3 · GitHub


說的都是事實。

從編程範式的角度來看,React 是混亂的。每個組件用 state 維護自己的狀態;從 props 獲取外部的狀態;通過給子組件設定 pros 來向下傳遞狀態;如果遇到需要跨級傳遞的,用 props 不方便,因此又有了 context。引入了函數式的概念,但是卻沒有函數式的實現,於是就是不斷地在概念上打補丁,概念套概念。

React 組件樹是函數化的,因此組件樹自身確實比較乾淨。屬性輸入,VDOM 輸出。但是總要和外界交互吧(Side Effeect),因此首先需要引入 Flux 或者 Redux,否則像獲取伺服器數據這種 Read Effect, 或者寫數據到伺服器這種 Write Effect 在哪裡完成呢?DOM 也是個 Side Effect,對 DOM 的Write Effect 一般不用你操心,React 負責把 VDOM 轉換成真實的 DOM。但是 React 卻通過組件生命周期方法,把真的 DOM 也暴露給你,讓你可以直接(或者通過jQuery)對 DOM 操作! 這到底是想給我們一種怎樣的編程範式?

這一切的原因我猜想首先是性能,不是沒有更好的編程範式。FRP/Cycle 就是比 React 設計得更科學,核心概念非常少、代碼更健壯、重用性更高。但是,性能代價也更大。最好的函數式演算法的性能也往往比不上命令式的。對於 Facebook 這樣工程導向第一的公司,性能應該是最重要的考慮因素。

其次就是思維習慣,完全採用 FRP 模式在大團體里是很難的,思維習慣不一樣。有很多問題也需要時間來證明。

React 目前的樣子,就是一種工程選擇,是性能、可靠性、易用性之間的一種妥協。不同的框架有不同的妥協原則。Cycle.js 的作者很清楚這一點,所以只是提出了 React 的缺點,同時提出了 Cycle.js 在這方面的優點。但是誰又沒有缺點呢?

* 另外,Cycle.js 的模塊化非常好。大量利用社區已有的資產,例如 rxjs, virtual-dom, hyperscript...。而且由於其函數化的本質,很多都是可以被替換(其他vdom實現),或者今後可以被替換的(例如替換frp庫,從rxjs到most等)。而 React 則秉承了 Facebook 喜歡發明輪子的特性,非常 monolithic。這點在react, react-native 里都有明顯的體現。


看到大段大段的 switch case 我已經醉了,從來沒見過真正用來 reduce 的 reducer 裡面帶 switch 的,命令式的 switch 語句來做 dispatching,不管怎麼都很 low(不包括模式匹配,scala/haskell黨 不要噴我),連最基本的單一職責和開放封閉都不滿足


推薦閱讀:

為什麼 React 推崇 HOC 和組合的方式,而不是繼承的方式來擴展組件?
說說對react中JSX語法的理解?
前端發展太快,有些小伙只會用react(了解api),招個jquery熟練的外包較難,如何看?
請問react中有什麼好用的ui庫嗎?
react服務端渲染如何將數據同步到客戶端?

TAG:前端開發 | React | Redux | Cyclejs |