基于 React 的組件化開發(fā)方式，為富前端 web 應用提供大量技術實踐，社區(qū)逐漸形成了穩(wěn)定的組件規(guī)范，本文從 API 層面歸納出 6 種組件類型，分析其優(yōu)缺點和適用場景，為日常組件開發(fā)提供一個方法指南。6 種類型分別為結(jié)構(gòu)型組件、樣式型組件、組合型組件、配置型組件、受控型組件、非受控組件。

結(jié)構(gòu)型組件與樣式型組件

結(jié)構(gòu)型組件定義了組件大體結(jié)構(gòu)，結(jié)構(gòu)的具體實現(xiàn)由外部傳遞。樣式型組件確定了組件結(jié)構(gòu)細節(jié)，外部只需傳遞參數(shù)即可渲染預期樣式。樣式型組件是較為常用的組件類型，很少有開發(fā)者會根據(jù)一份設計稿來推斷組件未來可能的改動，這也導致了樣式型組件在復用性與拓展性上偏弱。對于比較通用的組件，例如 Button 按鈕、Modal 彈框、Form 表單等，不應僅提供樣式型實現(xiàn)，應該抽象出結(jié)構(gòu)型組件。

這兩種類型并不是非此即彼的關系，樣式型組件固定的 API 參數(shù)可以降低使用成本，結(jié)構(gòu)型組件彈性的 API 設定可以提供擴展性，結(jié)合兩者的優(yōu)點可以構(gòu)造出既簡單又可拓展的組件。關于兩者結(jié)合的優(yōu)勢最具說服力的實踐是通用組件庫，結(jié)構(gòu)型組件可顯著降低業(yè)務方的溝通成本與接入風險，如下示意圖演示了業(yè)務方與組件庫之間的兩種溝通模型：

樣式型組件庫與業(yè)務方的溝通模型

結(jié)構(gòu)型組件庫與業(yè)務方的溝通模型

以上兩種模型每一個箭頭為一個工時，樣式型組件庫完成一次需求變更需要三個工時，業(yè)務方要等待組件庫實現(xiàn)功能后才能進行下一步。結(jié)構(gòu)型組件庫給予業(yè)務方更多的自主性，不用等待組件庫實現(xiàn)新特性，通過自定義結(jié)構(gòu)滿足當前需求，組件庫有充足的時間分析需求是否通用，是否值得提供新 API，結(jié)構(gòu)型組件在這個過程中扮演了緩沖區(qū)的角色，使得業(yè)務方與組件庫可以并行協(xié)同開發(fā)，確保各自的研發(fā)效率與節(jié)奏。

組合型組件與配置型組件

組合型組件以 JSX 為主體，通過組件間的嵌套組合描述業(yè)務邏輯。配置型組件通過 props 傳遞數(shù)據(jù)結(jié)構(gòu)，組件內(nèi)部根據(jù)預先設定好的邏輯渲染視圖。日常開發(fā)傾向于寫配置型組件，組合型組件更多的出現(xiàn)在通用組件庫中。

組合型組件結(jié)構(gòu)清晰，擴展性高，組件使用者通過閱讀 JSX 的 render 函數(shù)即可了解業(yè)務邏輯，但組件間聯(lián)系微弱，ref 引用相互隔離，難以構(gòu)建復雜的交互組件。配置型組件需要寫的代碼量少，但組件內(nèi)部渲染處于黑箱，使用者難以理解組件邏輯，使其在拓展性上偏弱。比較基礎的組件，例如 Form 表單，Select 選框等，建議采用組合型，有利于使用者組織業(yè)務代碼，復雜交互組件可使用配置型。

組合型組件最具代表性的實踐是 Ant Design，整個組件庫的 API 設計嚴格遵循組合型優(yōu)先原則，為同一組件的不同位面分別提供組合型結(jié)構(gòu)，使其在拓展性和易用性上都達到了很高的水準。如下示意圖演示了用兩種組件類型開發(fā) Select 選框的演化模型。

Select 簡單選框，組合型與配置型，都能提供清晰易用的接口

比較復雜的 Select 選框組，組合型組件通過提供新的子組件，仍可保持簡潔的 API 調(diào)用。配置型組件有兩種實現(xiàn)方式：提供新的屬性或者擴展原屬性，兩種方式都會產(chǎn)生一定認知成本。

對于需要自定義的 Select 選框組，組合型組件得益于 JSX 的嵌套結(jié)構(gòu)，可以很從容的提供自定義 API。配置型組件實現(xiàn)同樣的功能，需要再一次拓展屬性配置。

受控型組件與非受控組件

這兩種類型有另一種表述：無狀態(tài)組件和有狀態(tài)組件。受控型組件內(nèi)部只負責展示，僅對外提供回調(diào)，以表達改變的期望，其最終行為完全由外部驅(qū)動。非受控組件由內(nèi)部處理某些行為，并不強制外部狀態(tài)同步。官方推薦輸出無狀態(tài)受控組件，但是有狀態(tài)的組件在項目開發(fā)中仍是必要的。

受控型組件在自身層面規(guī)范了單向數(shù)據(jù)流，可以與其他數(shù)據(jù)層框架整合，但是開發(fā)一個復雜的受控型組件，開發(fā)者可能需要向外提供數(shù)不清的接口與回調(diào)。非受控組件較為智能，組件可以自主維護狀態(tài)，但開發(fā)者常常因此懶于做狀態(tài)同步，上層組件重新渲染時，非受控組件會丟失內(nèi)部的狀態(tài)，失憶，日常開發(fā)中大多數(shù)的 bug 因此而來。

我們經(jīng)常會以內(nèi)部是否擁有 state 來衡量一個受控型組件與非受控組件，但是完全遵守這條標準將很難提供一個簡單易用的大型受控組件，所有狀態(tài)都由外部控制，使用者需要寫大量配置代碼才能跑通一個大型組件，使用成本極高。官方提供的解決方案通過兩者結(jié)合的方式來處理受控與易用的矛盾，如下示意圖展示了一個 Input 組件可以接受的參數(shù)類型。

按照類型定義可推導出如下三種使用方式，分別對應一種受控型用法，和兩種非受控用法。

開發(fā)一個受控與非受控兼具的組件，對組件本身的開發(fā)與維護有更高的要求，其難度隨組件本身復雜度的增加而增加。但是對組件使用者來說，這種兩者兼具的組件最能適應快速開發(fā)與后期代碼調(diào)優(yōu)。任何有輸入輸出特性的組件(各種表單，配置 + 回調(diào)組件)，都可參照上述類型定義提供 API。

總結(jié)

React 組件本質(zhì)上是 JS 函數(shù)的另一種形態(tài)，一切與函數(shù)有關的思想都可以反映在組件里，每一種組件都有其適用場景，開發(fā)一個大型 Web 項目需要搭配使用不同類型的組件，如何做出合適搭配則需要長時間的開發(fā)積累，在真正的項目里尋找最優(yōu)解。