淺談前端組件設計

作者：ELab.yangyuqin 2023-02-27 09:10:57

由于Headless組件的抽象程度較高，所需的設計成本也更高，因此并不適用于所有前端場景。其更適合用于開發橫跨多個不同業務或跨端的通用組件，開發者需要在開發底層Headless組件和開發多套組件中衡量成本、作出抉擇。

本文為來自字節跳動-國際化電商-S 項目團隊成員的文章，已授權 ELab 發布。

?為何要進行前端組件設計？?

與僅承擔數據處理邏輯的后端不同，前端需要負責界面渲染、數據處理、和接口調用，在框架誕生前，更多地是編寫頁面維度的順序腳本代碼。隨著前端繼續的持續發展，ES6推出了class語法糖，React提出了函數式組件，Vue則以模版語法的形式組織代碼，前端代碼逐漸從“平鋪”轉變到了“層級”結構，從“面向過程”進階為“面向對象”，前端組件也成為了近幾年來的熱門議題。

“組件是對數據和方法的簡單封裝，是軟件中具有相對獨立功能、接口由契約指定、和語境有明顯依賴關系、可獨立部署、可組裝的軟件實體。”這段百科中摘取的組件定義，揭示了組件所需要具備的特性：功能獨立、約定一致、可集成、服務于場景。

在軟件工程中，軟件設計是軟件開發流程中的必要階段，在需求分析后、軟件開發前進行。軟件復雜度是每一個項目演進的產物，隨著需求和代碼行數的增加，復雜度將持續提升。軟件設計的優劣為對復雜度帶來的影響是不同的，優雅、合理的設計使待開發的代碼復雜度可控，而拙劣的設計將會給軟件帶來無序、偶然的復雜度變更。一個優秀的前端組件需要在滿足需求的前提下，具備高易用性和良好的可擴展性，這是我們進行前端組件設計的目標。

???如何提升組件易用性？?

合理的組件封裝

組件既生于頁面，又能夠獨立于頁面。我們不能將整個頁面雜糅為一個組件，也不能將每一小塊UI都封裝為組件。前端組件按類型可以分為容器組件、功能組件和展示組件，一個優秀的組件應該保證：功能內聚、樣式統一、并且與父元素僅通過Props通信。

組件的封裝粒度并不是越小越好，很多時候一個組件是在其他一個或多個組件的基礎上開發的，無法完全以功能點的數量衡量是否遵循單一職責原則，組件開發者需要根據組件功能和目標來確定組件封裝粒度：

當該組件需要承載具體的額外功能時，相較于新增 API ，封裝成獨立的組件是更好的選擇。

??：InputTag組件在 Input、Tag 的基礎上，增加了部分交互功能，API整合了兩個組件的屬性，作為一個全新的組件提供給開發者使用。相似的，InputNumber、AutoComplete、Mentions等組件也是基于單一職責原則封裝的特定功能組件。

當組件中存在可能被單獨使用、可以承載獨立功能的子組件時，可以將其以內部組件的形式提供。

??：圖片預覽功能通常依托著圖片組件使用，在實際系統中，喚起圖片預覽的觸發器不一定是圖片，可能是按鈕或其他觸發事件，因此預覽組件需要單獨提供給開發者使用。預覽組件作為 Image 的內部組件，開發者能夠以Image.Preview、Image.PreviewGroup的方式使用，并提供左右切換、圖片縮放等功能，用戶可以通過 srcList、visible、actions、scales等API來控制并定制化預覽組件。

規范的API編寫

一個易用的組件，使用者無需閱讀文檔或僅快速瀏覽文檔即可上手使用，并且應當在使用過程中給予清晰的注釋和代碼提示。希望以下API編寫建議能夠給組件開發者一些參考：

減少必填的API項，盡可能多地提供默認值，降低組件的使用成本；
使用通用且有意義的API命名：

onXXX：命名監聽/觸發方法
renderXXX：命名渲染方法
beforeXXX/afterXXX：命名前置/后置動作
xxxProps：命名子組件屬性
優先使用常見單詞進行命名，如：value、visible、size、disabled、label、type等等

單獨維護類型文件，并將其打包至組件產物包中，這樣使用者在開發過程中能夠實時看到對應的類型提示；
在類型文件中，為API編寫注釋；

[Slot] 與 [Props] 的選擇

使用Props存在的問題？

當我們需要實現一個較為復雜的卡片需求組件時，為了最大程度地還原UI、減少用戶的樣式開發成本，首次設計時我們會設計出這樣的API：

export type CardProps = {
  // 底部信息展示
  infoProps?: {
     title?: ReactNode;
     content?: ReactNode;
  };
  // 彈層信息展示
  moreInfoProps?: {
     info?: ReactNode;
     triggerProps?: TriggerProps;
     descriptionsProps?: DescriptionsProps;
  };
  className?: string;
  style?: CSSStyleSheet;
  width?: number | string;
  imageProps?: {
    srcList?: Array<SrcList>; // 圖片url數組
    afterImgs?: React.ReactNode; // 插槽，在圖片dom節點中
    aspectRatio?: string; // 寬高比  默認3:4
    buttonProps?: ButtonProps;
    current?: number; // 受控展示圖
    defaultCurrent?: number; // 默認展示圖
    onChangeCurrent?: (current: number) => undefined; // 設置current
    PreviewGroupProps?: ImagePreviewGroupProps;
    src?: string;
  };
  children?: React.ReactNode;
} & CardCheckboxProps;

可以看到，這個業務卡片組件是由多個不同組件組合而成，其承載了渲染和操作（選中操作、圖片切換和彈層操作），這個設計的缺陷是顯而易見的：

需要編寫很多分散的JSX代碼，無論是寫在Props中還是定義成單獨的組件，其可讀性都不高；
需要在Card組件中雜糅許多額外的Props，例如triggerProps和descriptionsProps，增加了該組件的學習成本；

如果以插槽的方式對Card組件進行改造，通過內部組件間的組合來實現需求，避免了大量組件Props的堆砌，層次清晰、可讀性高，這樣的組件結構明顯易用性更高。

<Card type="verticle" {...cardProps}>
  <CardImage {...ImageProps} />
  <CardContent {...InfoProps} >
      <div className="card-title">title</div>
      <div className="card-content">content</div>
      <Tag>Tag</Tag>
  </CardContent>
  <CardTrigger {...triggerProps}>
      <Description {...descriptionProps}/>
  </CardTrigger>
</Card>

什么是插槽(Slot)？

Slot是Vue框架提出的概念，可以理解為臨時占位，可以用其他組件進行填充，Slot能夠實現父組件向子組件分發內容的功能。Vue框架中提供了

使用 props.children 獲取子組件，若需要區分使用不同子組件，只能通過數組下標讀取。
使用 Props 傳遞 ReactNode 元素。
將組件劃分為多個內部組件，交由開發者自行組裝。

Slot(內部組件)的使用時機？

布局類組件優先使用Slot，為開發者提供更靈活的使用方式，參考Typography、Layout、Card等組件，開發者可以隨意地在這些組件內部插入自定義實現。上文提到的業務卡片組件，實質上也是一個封裝了多圖預覽功能的布局組件，因此更適合使用Slot來組織代碼。
內容復雜、定制化程度高的組件更適合使用Slot
功能類組件中，以Props傳遞ReactNode的方式來接管內部元素，盡量避免傳遞基礎類型元素進行展示。

// ? 擴展性低
type CardProps {
    title?: string;
    tags?: string[];
}
// ? 為開發者提供對應的“插槽”
type CardProps {
    title?: string | ReactNode;
    tag?: string[] | ReactNode;
}

???如何提升組件可擴展性？?

開閉原則：對擴展開放，模塊的行為可以被擴展；對修改關閉，模塊中的源代碼不應該被修改

將DOM交予用戶接管

在前端組件中，應該提供對應的API屬性或方法來支持額外的功能，給予開發者更充分的擴展空間，而不是有部分需求無法滿足時放棄使用組件。以 Cascader組件為例（以下例子若無特殊說明，均來自Arco組件庫），在通常情況下，僅需要使用左側的基礎選擇器即可滿足需求。

此時若開發者需要在級聯選擇器底部添加操作按鈕或文字展示，可能會直接修改組件源代碼、甚至放棄使用該組件。作為組件開發者，為了提升組件可擴展性，在此處增加了 dropdownRender?屬性，接收一個返回 ReactNode? 的函數，并將此 ReactNode 渲染在級聯選擇器的特定位置。

<Cascader
    optinotallow={options}
    dropdownRender={(menu) => {
      // menu 為所有選擇器元素
      return (
        <div>
          {menu}
          <Divider style={{ margin: 0 }} />
          <div style={{ margin: 4 }}>
            The footer content
          </div>
        </div>
      );
    }}
  />

與此類似的，還有 renderFooter、renderOption、renderFormat 等API，這些API實現難度并不高，一定程度上將DOM元素的掌控權交予組件使用者，作為通用組件，為開發者提供了部分功能和樣式的可擴展性。我們在設計前端組件時，多多留意組件中能夠接管給使用者的渲染邏輯和操作邏輯，并將這些邏輯暴露出去。

設計可擴展的API

組件開發前，整理組件所需實現的功能，并以功能為維度設計組件API。以下是一個設計移動端選擇器的例子，這個選擇器需要支持單選、多選和時間選擇，于是這樣寫了第一版API??，它可以滿足我們當前的選擇器需求。

type PickerProps {
    dataSource?: PickerData[] | PickerData[][];
    multiple?: boolean; // 是否多選
    time?: boolean; // 是否時間選擇
    value?: (string|number)[];
    onChange?: (value: (string|number)[]) => void;
    ...
}

在后續迭代中發現還有地區選擇和級聯選擇的需求，選擇器需要進行優化更新，在以上API的基礎上只能通過添加cascader、region兩個布爾值字段用于標識不同選擇需求。這樣做的缺陷是很明顯的，每當我們新增不同類型的選擇功能，都需要新增一個API字段，并且這些字段還是互斥關系。理清問題后，更新了第二版API??。在組件庫中很多API都設計為常量枚舉值的形式，即使其只有兩個取值，這樣擴展性相較于布爾值類型更好。

type PickerProps {
    dataSource?: PickerData[] | PickerData[][];
    type?: "single" | "multiple" | "cascader" | "region" | "time"; // 選擇器類型
    value?: (string|number)[];
    onChange?: (value: (string|number)[]) => void;
    ...
}

除上述例子外，還可以利用ts的泛型和可選類型來實現API擴展，例如 Table 組件的pagination、border等字段，既可以直接設置為true/false，也能夠以對象的形式進行更詳細的配置。

極致的擴展性——Headless UI

首次接觸headless概念是在chrome瀏覽器中，在headless模式下用戶無需看到網頁界面即可進行網頁操作，現在廣泛用于web自動化測試和爬蟲場景中。與之相似的，Headless UI 是基于 React Hooks 的組件開發設計理念，強調只負責組件的狀態及交互邏輯，不關注組件的樣式實現。其本質思想其實就是關注點分離，將組件的“狀態及交互邏輯”和“UI 展示層”實現解耦。

Headless UI目前有兩種主流實現方式，其一是將組件劃分為多個原子組件，使用者可以通過填充組件或修改樣式的方式來實現自己的需求，其二是以Hooks的方式暴露內置交互功能的子組件屬性，使用者可以將這些屬性應用于任意組件上，由于沒有將樣式封裝到組件中，Headless組件實現了最大程度的視圖層可擴展性。

<NumberInput>
  <NumberInputField />
  <NumberInputStepper>
    <NumberIncrementStepper />
    <NumberDecrementStepper />
  </NumberInputStepper>
</NumberInput>

// chakra-ui 提供的數字增減框組件
function HookUsage() {
  const { getInputProps, getIncrementButtonProps, getDecrementButtonProps } =
    useNumberInput({
      step: 0.01,
      defaultValue: 1.53,
      min: 1,
      max: 6,
      precision: 2,
    })

  const inc = getIncrementButtonProps()
  const dec = getDecrementButtonProps()
  const input = getInputProps()

  return (
    <HStack maxW='320px'>
      <Button {...inc}>+</Button>
      <Input {...input} />
      <Button {...dec}>-</Button>
    </HStack>
  )
}

?Reference?

https://arco.design/react/docs/start

https://juejin.cn/post/7160223720236122125

https://juejin.cn/post/6844904032700481550

責任編輯：武曉燕來源： ELab團隊

前端組件設計