基於Decorator的組件擴展實踐

在前端業務開發中，組件化已經成為我們的共識。沉澱和復用組件，是提高開發效率的利器。但在組件復用的過程中，我們往往會遇到這樣的問題，組件相似，卻在結構或交互上有些許差別，需要對組件進行改造方可滿足需求。這個問題之前在 @瓊玖 的文章 React實踐 - Component Generator 就有所提及。

之初，我們提出了組件配置式。在業務統一的情況下，僅僅修改組件用於配置的props就可以滿足業務需求。但隨著業務發生變化導致組件形態發生變化時，我們就必須不斷增加配置去應對變化，便會出現配置泛濫，而在擴展過程中又必須保證組件向下兼容，只增不減，使組件可維護性的降低。

最近的項目開發中，@Jason 提出了組件組合式開發思想，有效地解決了配置式所存在的一些問題。下面我將詳細闡述其思想與具體實現。

組件再分離

對於組件的 view 層，我們期望組件是沒有冗餘的，組件與組件間 view 重疊的部分應當被抽離出來，形成顆粒度更細的組件，使組件組合產生更多的可能。

這種 view 細化的組合式思想早已在我們團隊可視化庫 Recharts 中有所體現。Recharts 避免了複雜的圖表配置，而將圖表進行有效拆分，通過聲明式的標籤進行組合，從而使圖表更具擴展性。

同樣，我們在組件上也希望秉承這種思想，先來看一下在現有業務比較典型的三個公共組件:

這三個組件無論在 UI 還是邏輯上均存在一定共性。在配置式中，我們會將這三個組件通過一個組件的配置變換來實現，但無疑會提高單個組件內部邏輯的複雜性。

再做一次分離！它們可由 SelectInput、SearchInput 與 List 三個顆粒度更細的組件來組合。而對於顆粒度最細的組件，我們希望它是純粹的，木偶式的組件。

例如 SelectInput 組件，組件狀態完全依賴傳入的 props，包括 selectedItem (顯示用戶所選項)、isActive (當前下拉狀態)、onClickHeader (反饋下拉狀態)以及 placeholder (下拉框提示)。我們來看一下它的簡要實現:

class SelectInput extends Component { static displayName = "SelectInput"; render() { const { selectedItem, isActive, onClickHeader, placeholder } = this.props; const { text } = selectedItem || {}; return ( <div onClick={onClickHeader}> <Input type="text" disabled value={text} placeholder={placeholder} /> <Icon className={isActive} name="angle-down" /> </div> ); }}

當組件被再次分離後，我們可以根據業務中的組件形態對其進行任意組合，形成統一層，擺脫在原有組件上擴展的模式，有效提高組件的靈活性。

邏輯再抽象

那麼有了 view 細化再重組的公共組件後，是不是就可以愉快地開發了?

是的，但組件層面的抽象不應該只停留在 view 層面，組件中的相同交互邏輯和業務邏輯也應該進行抽象。

@誠身 的文章 ReactEurope 2016 小記 - 上 中提到復用高階函數的思想，編寫 Higher-Order Components (高階組件)來為基礎組件增加新的功能。

Higher-Order Components = Decorators + Components。在我們的組件中，也正是貫穿著這樣函數式的思想，來完成組件邏輯上的抽象，例如:

// 完成SearchInput與List的交互const SearchDecorator = Wrapper => { class WrapperComponent extends Component { handleSearch(keyword) { this.setState({ data: this.props.data, keyword, }); this.props.onSearch(keyword); } render() { const { data, keyword } = this.state; return ( <Wrapper {...this.props} data={data} keyword={keyword} onSearch={this.handleSearch.bind(this)} /> ); } } return WrapperComponent;};// 完成List數據請求const AsyncSelectDecorator = Wrapper => { class WrapperComponent extends Component { componentDidMount() { const { url } = this.props; fetch(url) .then(response => response.json()) .then(data => { this.setState({ data, }); }); } render() { const { data } = this.state; return ( <Wrapper {...this.props} data={data} /> ); } } return WrapperComponent;}

擁有 Decorator 之後，我們就能賦予組件能力了，例如合成 Search 組件:

@SearchDecoratorclass Search extends Component { render() { return ( <Selector {...this.props} > <SearchInput /> <List /> </Selector> ); }}

那麼當我們將邏輯抽象成為多個 Decorator 時，又該如何去組合呢？你是否還記得 @流形 的文章 React Mixin 的前世今生 中提到的方法？沒錯，就是compose！這裡建議讀者 review 這篇文章，順便回顧一下Mixin與高階組件的不同點。

// SelectedItemDecorator為List與SelectInput的交互，讀者可以自行嘗試實現const FinalSelector = compose(AsyncSelectDecorator, SearchDecorator, SelectedItemDecorator)(Selector);class SearchSelect extends Component { render() { return ( <FinalSelector {...this.props} > <SelectInput /> <SearchInput /> <List /> </FinalSelector> ); }}

小結

在配置式組件內部，組件與組件間以及組件與業務間是緊密關聯的，而對於開發人員而言需要完成的僅僅是配置的工作。而組合式意圖打破這種關聯，尋求單元化，通過顆粒度更細的基礎組件與抽象組件共有交互與業務邏輯的 Decorator，使組件更靈活，更易擴展，也使開發者能夠完成對於基礎組件的自由支配。

雖然組合式確實能解決配置式所存在的一些問題，但多層 Decorator 帶來的多層包裹，會對組件理解和調試造成一定困難，也"不能"使用外部公有的方法。同時組合式所基於的函數式編程的思想能否被整個團隊所接受，也是我們需要考量的問題。