React 組件設計思路？

01-05

最近在開發一些通用的 React 組件，但是當一個組件功能越來越多，比如：
椅子 VS 帶輪子的黑色真皮椅
不想把所有可能的功能集成到一個組件下（例如某 dataTable 插件幾千行代碼。。。），我的想法是組件獨立：椅子、帶輪子的椅子，但是繼續增加功能點的話，組件的數量是指數級的（排列組合），也想到用高階組件的方式去組合。

現在比較迷惑，總覺得沒有完美的方式。軟體開發中，這種情況業界有一些比較認同的思想去解決嗎？

react 說到底也只是通過程序提供的工具，僅僅是工具，而且是受到一些程序限制的工具。實際業務當中遇到的各種各樣的抽象，我認為是另一個緯度的東西。react 的設計足夠靈活，但未必意味著適合做全部的抽象。而組件的問題並不是 react 帶來或者能解決的問題，而是所有程序面臨的問題。我傾向於認為 react 沒有完美的解法。

早上剛翻了一下：《React 引領未來的用戶界面開發框架》的序。。。

引用一下劉平川的序3：

越靠近用戶端變化越快，用枚舉組件的思路在高速迭代快速變化的互聯網中開發，將會使UI組件庫逐漸變得臃腫和難以維護。.... UI組件受具體業務場景的約束。
而組件庫在公司級別難抽象，對整體技術的挑戰比較大，且收效不確定。於是只能將組件場景定位到更具體的某一類型的業務線再進行抽象。從而讓組件庫變得輕量、靈活。

我覺得題主的問題不在於如何用react或者其他框架提供一個功能豐富的椅子。而是應該根據業務場景，定製靠譜的通用的幾把椅子。拒絕生產造型奇葩、功能小眾的椅子，為個別合理的特殊需求的椅子預留一下開發介面

寫通用組建比寫項目組建複雜度提升很多。我能想到三種方式，高階組件，wrapper，屬性。

高階組件 higher order component：首先要搞清楚什麼是高階組件，這是一個參數和返回值都是React Component的函數，一般給組建添加比較通用的功能的時候用。比如題主例子裡帶輪子的就適合使用高階組件實現，它可以被抽象出來用於不同的組件。比如帶輪子的() 這個高階組件，可以接受 &<桌子&> 或者 &<椅子&> 當參數，返回 &<帶輪子的椅子&> 或者 &<帶輪子的桌子&>。如果要對這個輪子做自定義，那麼可以變成帶輪子的(options)(組件)的形式。

wrapper就是一個容器組件，比如一個桌子，上面擺了各式各樣的東西，那桌子這個組件就是wrapper，並對自己的children做規範。使用實例就是

&<桌子大小={500}&>

&<筆 /&>

&<紙 /&>

&<... 其他什麼東西 /&>

屬性就好理解了，就是對組件本身定義。

題主的例子帶輪子的真皮黑色椅子就可以理解為帶輪子是一個功能，能適用於其他組建，黑色和真皮都是描述這個椅子的，所以用屬性。就是

帶輪子的(&<椅子材質="真皮" 顏色="黑色" /&>)。

軟體開發中解決這類問題有類式繼承-面向對象編程、mixin-面向切面編程。

帶輪子的黑色真皮椅 = 椅子 mixin [帶輪子,黑色,真皮];

我一般也只是用高階組件。

組件：

椅子

輪子

真皮，能改變顏色

組合過的組件：

&<真皮椅子 /&> =

&<椅子 /&>

&<真皮顏色=黑色/&>

&<真皮輪子椅子 /&> =

&<椅子 /&>

&<真皮顏色=黑色/&>

&<輪子 /&>

其實不必須提供功能點的排列組合，可以讓使用者自己按需的使用組合。可以參考GitHub - react-component/calendar: React Calendar 的方式。

不過這種方式的話，組件就需要一個比較健全的文檔和使用教程，不然很容易暈。

所以定義邊界是一項很重要的事情。就算是通用部件，也不可能適合所有情況。我更傾向於，在特定的應用範圍做到部件本身更輕量切適度的抽象（react感覺對於抽象的處理還是很簡單和局限的），然後在用到實際項目中，來不斷豐富特性吧……然後越來越重，越來越不通用。

猜想你有很多種椅子，那應該可以用繼承來做。並不需要全部捆到一個組件里。

如果設計的時候必須考慮所有的場景，適應所有的可能的話，可能永遠也寫不出一個組件了。

用重構去改善設計。

其實我寫了還算蠻多的組件，大部分是這樣的：自己要用什麼組件，第一版不用考慮太多，實現自己想要的功能就行。然後再看自己的代碼，哪些方法是通用的，其他程序可能也會用到，如果這些代碼和React無關，那麼就改成純函數，丟到utils下面去。然後再看，寫完的這個組件和其他的組件有沒有什麼通用的地方，有的話，就抽出來，做一個高階組件。

高階組件的使用，推薦函數式的compose。例如

&<真皮&> - 高階組件

&<輪子&> - 高階組件

&<椅子&> - 組件

compose(&<真皮&>, &<輪子&>)(椅子) =&> 真皮輪椅

compose(&<輪子&>)(椅子) =&> 輪椅

compose(&<真皮&>)(椅子) =&> 真皮椅子

虛擬DOM不僅帶來了簡單的UI開發邏輯，同時也帶來了組件化開發的思想，所謂組件，即封裝起來的具有獨立功能的UI部件。React推薦以組件的方式去重新思考UI構成，將UI上每一個功能相對獨立的模塊定義成組件，然後將小的組件通過組合或者嵌套的方式構成大的組件，最終完成整體UI的構建。例如，Facebook的http://instagram.com整站都採用了React來開發，整個頁面就是一個大的組件，其中包含了嵌套的大量其它組件，對於React而言，則完全是一個新的思路，開發者從功能的角度出發，將UI分成不同的組件，每個組件都獨立封裝。http://tinyurl.com/hbapn5s

我覺得我們在開發中經常忽略掉的一個模式就是所謂的Stateless Functional Component，不過這是我個人最愛的React組件優化模式，沒有之一。http://tinyurl.com/hbapn5s我喜愛這種模式不僅僅因為它們能夠減少大量的模板代碼，而且因為它們能夠有效地提高組件的性能表現。總而言之，SFC能夠讓你的應用跑的更快，長的更帥。

首先是一個椅子，可以帶有以下屬性

顏色
材質
是否有輪子
(大小)
(是否只能自帶按摩震動等題注需要的功能)

於是問題就解決了啊，如果需要輪子，那麼就給他一個輪子（輪子肯定是一個小組件~），如果需要白色，就設置白色~