:root{
????--bg-default:?#fff;
}
:root[theme="dark"]{
????--bg-default:?#000;
}
.button{
????background-color:?var(--bg-default);
}

//?處理前
.button{
????background-color:?var(--bg-default);
}

//?處理后
.button{
??? background-color：?#fff;?//?對于不支持css變量的瀏覽器這行會生效
????background-color:?var(--bg-default);?//?對于支持css變量的瀏覽器這行會覆蓋上一行屬性
}

.button{
????background-color:?#fff;
}
.theme-a?.button{
????background-color:?#000;
}
.thema-b?.button{
????background-color:?#ccc;
}

:root{
????--bg-default:?#fff;
}
@media?(prefers-color-scheme:?dark)?{
????:root{
????????--bg-default:?#000;
????}
}
//?支持白名單逃逸，再寫一次:root下的屬性
:root[theme="light"]{
????--bg-default:?#fff;
}

????
????"root">

樣式的部分就像我們一開始介紹 CSS 變量的例子：

:root{
????--bg-default:?#fff;
}
:root[theme="dark"]{
????--bg-default:?#000;
}

這個(gè)方案的好處是靈活，可以很容易地在腳本里加入其它邏輯支持白名單逃逸。缺點(diǎn)是為了支持 SSR，需要單獨(dú)將這部分腳本寫在 html 模板的 body 元素內(nèi)最上方，對于組件庫的使用方增加接入成本。

小結(jié)：從實(shí)際業(yè)務(wù)可能出現(xiàn)的白名單逃逸問題以及業(yè)務(wù)的變化來看，雖然使用 JS API 監(jiān)聽媒體查詢判斷 Dark Mode 的方式會少許增加接入組件庫的成本。但是和帶來的靈活性收益相比來說是值得的，建議使用這種方式。

RTL 適配

組件庫如果支持國際化，那么 RTL 是一個(gè)必不可少的部分。RTL(right to left) 是指部分語言，例如阿拉伯語是從右往左閱讀的，由此帶來 UI 上需要左右相反（大部分情況下，有些例外），一些 icon 也需要鏡像，手勢也是從右往左滑動的，input 輸入框從右到左輸入，更多細(xì)節(jié)具體可以參考?《bidirectionality - Material》^[5]。

布局適配

我們可以利用原生的?dir 屬性^[6]來支持大部分的 rtl 能力，即在 html 上設(shè)置屬性 dir='rtl'。在瀏覽器環(huán)境下可以通過 NavigatorLanguage API 來獲取頁面語言，進(jìn)而根據(jù)當(dāng)前語言是否是 rtl 來設(shè)置 dir 的值。在 node 環(huán)境下可以通過請求頭 Accept-Language 獲取頁面語言，判斷得到 dir 的值后注入到返回的頁面中。設(shè)置 dir='rtl'后，全局的 flex 水平布局會自動反向，文本也會自動右對齊（除非顯示聲明 text-align）。但包括 marin-left、left、border-left 這類屬性(其他方向類似)無法自動適配，解決這個(gè)問題有多種方式，我們可以很直觀地來看代碼：

//?方法1：?樣式覆蓋方式，ant design使用此方式
.button{
????margin-left:?16px;
}
html[dir='rtl']?.button{
????margin-left:?0;//?要覆蓋掉，否則左右都是16px的margin
????margin-right:?16px;
}


//?方法2：?另一種方式，雖然不用覆蓋，但是需要將方位屬性拆出來
.button{
???//?與方位無關(guān)的屬性
}
html[dir='ltr']?.button{
????margin-left:?16px;
}
html[dir='rtl']?.button{
????margin-right:?16px;
}

//?方法3：?方法2 + Atomic CSS
html[dir='ltr']?.ms-16{
????margin-left:?16px;
}
html[dir='rtl']?.ms-16{
????margin-right:?16px;
}

我們可以看到方法 1 和方法 2 都不是很方便，而方法 3 需要 UI 非常的規(guī)范化（將 margin、padding 收斂到可枚舉的狀態(tài)），也不能覆蓋所有的情況。幸運(yùn)的是，我們可以使用 margin-inline-start 這類 RTL 敏感的屬性來解決（更多屬性見CSS Logical Properties^[7]） ：

.button{
???//?其他屬性
???margin-inline-start:?16px;
}

在實(shí)際使用中還存在一些兼容性問題，我們可以使用?postcss-bidirection^[8]?處理，會把上述聲明轉(zhuǎn)化為：

.button{
????//?其他屬性
}
html[dir="ltr"]?.button?{
????margin-left:?16px;
}
html[dir="rtl"]?.button?{
????margin-right:?16px;
}

小結(jié)：RTL 的布局適配我們可以使用 RTL 敏感屬性，它與 Atomic CSS 不沖突，合適的情況下可以結(jié)合起來使用。

icon 適配

在 RTL 下，部分 icon 需要鏡像。前面我們已經(jīng)介紹，icon 的最佳方式是使用 svgr 將 svg 轉(zhuǎn)換為 React Component。這樣，我們可以在轉(zhuǎn)換時(shí)為需要 RTL 翻轉(zhuǎn)的 icon 增加一個(gè) class，例如 flip-rtl，然后組件庫提供以下 CSS 聲明供業(yè)務(wù)使用：

[dir="rtl"]?.flip-rtl?{
??transform:?scaleX(-1);
}

icon 是否鏡像可能是偏設(shè)計(jì)側(cè)的事情，如果我們將 icon 的設(shè)計(jì)稿托管在 figma 平臺上，我們可以和設(shè)計(jì)師約定需要 RTL 下需要翻轉(zhuǎn)的 icon 的命名，然后實(shí)現(xiàn)一個(gè)自動下載 svg 源文件、 svgo 處理、 使用 svgr 轉(zhuǎn)換成 React Component 的腳本，并且在轉(zhuǎn)換過程中根據(jù)命名自動判斷是否需要加上 flip-rtl 這個(gè) class。這樣，在組件庫和業(yè)務(wù)開發(fā)過程中，研發(fā)都不需要關(guān)心 icon 的鏡像問題，減少溝通和驗(yàn)收成本。

手勢適配

一些組件，如進(jìn)度條組件，在傳統(tǒng) LTR 下是從左向右滑動，但是在 RTL 下則是從右向左滑動。我們可以簡單地給這類組件增加一個(gè) isRTL 這種 props，但是這顯然不是一種很好的做法，使用的時(shí)候都要計(jì)算并傳入 props 值。由此思考，我們可以為整個(gè)組件庫抽象一些通用能力，全局注入。

全局化配置

對于 direction(LTR/RTL)、 prefixCls(類名前綴)等一些全局配置，我們可以使用 React 的 Context 來注入，例如應(yīng)用的根節(jié)點(diǎn)外面包裹一個(gè) ConfigProvider：

import?ConfigProvider?from?'myComponent';
//?...
export?default?()?=>?(
??"rtl">
????
??);

在組件中使用 hooks 獲取：

import?{?useConfigContext?}?from?'myComponent';
export?default?()?=>?{
????const?{?rtl,?prefixCls,?platform?}?=?useConfigContext();
????//...
}

使用 Context 甚至可以實(shí)現(xiàn)局部的配置和全局不同，它非常靈活，后期可以很方便地?cái)U(kuò)展全局配置的能力，也解決了我們反復(fù)將一些全局通用的屬性作為 props 傳入各個(gè)組件的痛點(diǎn)，缺點(diǎn)在于不利于代碼的靜態(tài)測試。

組件分層

在組件庫開發(fā)之前，應(yīng)該先規(guī)劃好組件庫的層級，以增加組件庫的代碼復(fù)用性和使用的靈活性。

我們應(yīng)該先規(guī)劃一些基礎(chǔ)組件，避免后續(xù)的重構(gòu)。Switch、Checkbox、Radio（它們在邏輯上區(qū)別僅僅在于點(diǎn)擊激活態(tài)后是取消還是依舊激活）可以抽象出一個(gè) BaseSwitch，在它的基礎(chǔ)上實(shí)現(xiàn)這三個(gè)組件。對于 Button，在彈窗組件等其他組件中也會出現(xiàn)，我們可以抽象出一個(gè) BaseButton 或者在其他組件中使用 ConfigProvier 的 prefixCls 重寫它的樣式。對于表單相關(guān)的組件，可以先實(shí)現(xiàn)一些原子的 input、textarea，再實(shí)現(xiàn) Form 中帶有 lable、 校驗(yàn)狀態(tài)等和 UI 跟相關(guān)的 Form.input 等。對于彈層組件，可以封裝一個(gè) Portal 組件提供能力等等。在 Metrial UI 中還抽象了一個(gè) Box 組件，所有的組件都基于 Box 組件編寫，實(shí)現(xiàn)全局布局和樣式的控制。

樣式

樣式上，如果沒有使用 Atomic CSS，我們可以將 UI 規(guī)范（字重、文本大小和行高的組合）封裝成 sass/less 中的 mixin，降低出錯(cuò)的可能性。還可以封裝一些常用的能力，比如文本溢出顯示省略號、 0.5px 邊框的偽元素實(shí)現(xiàn)等。這些封裝的變量和 mixin 不僅可以在組件庫內(nèi)部使用，還可以提供給業(yè)務(wù)方使用（尤其在定制組件庫中）。同時(shí)要和 UI 約定組件庫不同組件的 z-index，以避免不符合預(yù)期的層級。

其他

組件庫中用到的一些 hooks（比如彈層組件用到的凍結(jié)頁面的滾動）可以使用 react-use 等主流開源庫，也可以定制開發(fā)。如果組件庫期望支持 preact(一個(gè)和 react 語法基本一致但更輕量的庫)，可以參考?switching-to-preact^[9]?來避免在開發(fā)過程中使用不支持 preact 的語法。同時(shí)，組件庫中用到的 utils(一些函數(shù)能力)也要考慮兼容 node 環(huán)境，以支持 SSR。在不會引入特別大的成本的前提下，組件庫應(yīng)該充分地去考慮業(yè)務(wù)方可能的技術(shù)選型，以避免限制業(yè)務(wù)上的技術(shù)實(shí)現(xiàn)。

組件庫構(gòu)建一般使用 tsc 或者 rollup，動畫庫則根據(jù)具體需求選擇是否使用（使用 CSS 動畫更輕量）。

組件庫的其他細(xì)節(jié)

質(zhì)量保障

組件庫的質(zhì)量保障從流程上來說，主要是 code review 和嚴(yán)格的 UI 驗(yàn)收、QA 測試等流程。從技術(shù)層面來說可以收斂發(fā)包權(quán)限，結(jié)合?semantic-release^[10]?在 CI/CD 中實(shí)現(xiàn)自動發(fā)包，杜絕研發(fā)過程中在非 master 分支上隨意發(fā)包的危險(xiǎn)操作。還有單元測試、快照測試、e2e 測試等常用的技術(shù)手段，限于本文篇幅不再詳細(xì)闡述。

規(guī)范

制定規(guī)范的目的在于保證質(zhì)量、 方便業(yè)務(wù)方使用和增加組件庫的可擴(kuò)展性。比如上文提到的對于樣式的封裝、常用 mixin 封裝，強(qiáng)制使用顏色變量等。還有設(shè)計(jì)統(tǒng)一的組件庫 API 風(fēng)格規(guī)范，能降低業(yè)務(wù)方的使用成本。

提效

組件庫一般有一個(gè)演示站點(diǎn)，主流的技術(shù)選型有 stylegudist、storybook 等，可以根據(jù)團(tuán)隊(duì)習(xí)慣選用。對于移動端組件庫，可以通過 webpack 別名的方法重寫它們的組件，以支持移動端預(yù)覽，方便 UI 驗(yàn)收。對于國際化的組件，可以提供類似 vconsole 形式的 devtools，可視化切換 dark/light Mode、rtl/lrt 等能力，提高開發(fā)和測試流程中的效率。

一些思考

組件庫的開發(fā)是一個(gè)強(qiáng)依賴 UI 的事情，我們需要和 UI 進(jìn)行充分的溝通。同時(shí)我們不能局限于組件庫本身，而要考慮到開發(fā)、測試過程中的效率，業(yè)務(wù)中接入的難易，以及是否能良好地應(yīng)對業(yè)務(wù)的變化等，從更全局的視角去思考。另外，如果是通用組件庫，則組件庫的推廣是一個(gè)重中之重的事情，有更多的業(yè)務(wù)方接入，才能推動組件庫的進(jìn)一步迭代，形成良性循環(huán)。

參考資料

?點(diǎn)擊閱讀原文，快來加入我們吧！