: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;
}

这个方案的好处是灵活，可以很容易地在脚本里加入其它逻辑支持白名单逃逸。缺点是为了支持 SSR，需要单独将这部分脚本写在 html 模板的 body 元素内最上方，对于组件库的使用方增加接入成本。

小结：从实际业务可能出现的白名单逃逸问题以及业务的变化来看，虽然使用 JS API 监听媒体查询判断 Dark Mode 的方式会少许增加接入组件库的成本。但是和带来的灵活性收益相比来说是值得的，建议使用这种方式。

RTL 适配

组件库如果支持国际化，那么 RTL 是一个必不可少的部分。RTL(right to left) 是指部分语言，例如阿拉伯语是从右往左阅读的，由此带来 UI 上需要左右相反（大部分情况下，有些例外），一些 icon 也需要镜像，手势也是从右往左滑动的，input 输入框从右到左输入，更多细节具体可以参考 《bidirectionality - Material》^[5]。

布局适配

我们可以利用原生的 dir 属性^[6]来支持大部分的 rtl 能力，即在 html 上设置属性 dir='rtl'。在浏览器环境下可以通过 NavigatorLanguage API 来获取页面语言，进而根据当前语言是否是 rtl 来设置 dir 的值。在 node 环境下可以通过请求头 Accept-Language 获取页面语言，判断得到 dir 的值后注入到返回的页面中。设置 dir='rtl'后，全局的 flex 水平布局会自动反向，文本也会自动右对齐（除非显示声明 text-align）。但包括 marin-left、left、border-left 这类属性(其他方向类似)无法自动适配，解决这个问题有多种方式，我们可以很直观地来看代码：

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


// 方法2： 另一种方式，虽然不用覆盖，但是需要将方位属性拆出来
.button{
   // 与方位无关的属性
}
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 非常的规范化（将 margin、padding 收敛到可枚举的状态），也不能覆盖所有的情况。幸运的是，我们可以使用 margin-inline-start 这类 RTL 敏感的属性来解决（更多属性见CSS Logical Properties^[7]） ：

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

在实际使用中还存在一些兼容性问题，我们可以使用 postcss-bidirection^[8] 处理，会把上述声明转化为：

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

小结：RTL 的布局适配我们可以使用 RTL 敏感属性，它与 Atomic CSS 不冲突，合适的情况下可以结合起来使用。

icon 适配

在 RTL 下，部分 icon 需要镜像。前面我们已经介绍，icon 的最佳方式是使用 svgr 将 svg 转换为 React Component。这样，我们可以在转换时为需要 RTL 翻转的 icon 增加一个 class，例如 flip-rtl，然后组件库提供以下 CSS 声明供业务使用：

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

icon 是否镜像可能是偏设计侧的事情，如果我们将 icon 的设计稿托管在 figma 平台上，我们可以和设计师约定需要 RTL 下需要翻转的 icon 的命名，然后实现一个自动下载 svg 源文件、 svgo 处理、 使用 svgr 转换成 React Component 的脚本，并且在转换过程中根据命名自动判断是否需要加上 flip-rtl 这个 class。这样，在组件库和业务开发过程中，研发都不需要关心 icon 的镜像问题，减少沟通和验收成本。

手势适配

一些组件，如进度条组件，在传统 LTR 下是从左向右滑动，但是在 RTL 下则是从右向左滑动。我们可以简单地给这类组件增加一个 isRTL 这种 props，但是这显然不是一种很好的做法，使用的时候都要计算并传入 props 值。由此思考，我们可以为整个组件库抽象一些通用能力，全局注入。

全局化配置

对于 direction(LTR/RTL)、 prefixCls(类名前缀)等一些全局配置，我们可以使用 React 的 Context 来注入，例如应用的根节点外面包裹一个 ConfigProvider：

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

在组件中使用 hooks 获取：

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

使用 Context 甚至可以实现局部的配置和全局不同，它非常灵活，后期可以很方便地扩展全局配置的能力，也解决了我们反复将一些全局通用的属性作为 props 传入各个组件的痛点，缺点在于不利于代码的静态测试。

组件分层

在组件库开发之前，应该先规划好组件库的层级，以增加组件库的代码复用性和使用的灵活性。

我们应该先规划一些基础组件，避免后续的重构。Switch、Checkbox、Radio（它们在逻辑上区别仅仅在于点击激活态后是取消还是依旧激活）可以抽象出一个 BaseSwitch，在它的基础上实现这三个组件。对于 Button，在弹窗组件等其他组件中也会出现，我们可以抽象出一个 BaseButton 或者在其他组件中使用 ConfigProvier 的 prefixCls 重写它的样式。对于表单相关的组件，可以先实现一些原子的 input、textarea，再实现 Form 中带有 lable、 校验状态等和 UI 跟相关的 Form.input 等。对于弹层组件，可以封装一个 Portal 组件提供能力等等。在 Metrial UI 中还抽象了一个 Box 组件，所有的组件都基于 Box 组件编写，实现全局布局和样式的控制。

样式

样式上，如果没有使用 Atomic CSS，我们可以将 UI 规范（字重、文本大小和行高的组合）封装成 sass/less 中的 mixin，降低出错的可能性。还可以封装一些常用的能力，比如文本溢出显示省略号、 0.5px 边框的伪元素实现等。这些封装的变量和 mixin 不仅可以在组件库内部使用，还可以提供给业务方使用（尤其在定制组件库中）。同时要和 UI 约定组件库不同组件的 z-index，以避免不符合预期的层级。

其他

组件库中用到的一些 hooks（比如弹层组件用到的冻结页面的滚动）可以使用 react-use 等主流开源库，也可以定制开发。如果组件库期望支持 preact(一个和 react 语法基本一致但更轻量的库)，可以参考 switching-to-preact^[9] 来避免在开发过程中使用不支持 preact 的语法。同时，组件库中用到的 utils(一些函数能力)也要考虑兼容 node 环境，以支持 SSR。在不会引入特别大的成本的前提下，组件库应该充分地去考虑业务方可能的技术选型，以避免限制业务上的技术实现。

组件库构建一般使用 tsc 或者 rollup，动画库则根据具体需求选择是否使用（使用 CSS 动画更轻量）。

组件库的其他细节

质量保障

组件库的质量保障从流程上来说，主要是 code review 和严格的 UI 验收、QA 测试等流程。从技术层面来说可以收敛发包权限，结合 semantic-release^[10] 在 CI/CD 中实现自动发包，杜绝研发过程中在非 master 分支上随意发包的危险操作。还有单元测试、快照测试、e2e 测试等常用的技术手段，限于本文篇幅不再详细阐述。

规范

制定规范的目的在于保证质量、 方便业务方使用和增加组件库的可扩展性。比如上文提到的对于样式的封装、常用 mixin 封装，强制使用颜色变量等。还有设计统一的组件库 API 风格规范，能降低业务方的使用成本。

提效

组件库一般有一个演示站点，主流的技术选型有 stylegudist、storybook 等，可以根据团队习惯选用。对于移动端组件库，可以通过 webpack 别名的方法重写它们的组件，以支持移动端预览，方便 UI 验收。对于国际化的组件，可以提供类似 vconsole 形式的 devtools，可视化切换 dark/light Mode、rtl/lrt 等能力，提高开发和测试流程中的效率。

一些思考

组件库的开发是一个强依赖 UI 的事情，我们需要和 UI 进行充分的沟通。同时我们不能局限于组件库本身，而要考虑到开发、测试过程中的效率，业务中接入的难易，以及是否能良好地应对业务的变化等，从更全局的视角去思考。另外，如果是通用组件库，则组件库的推广是一个重中之重的事情，有更多的业务方接入，才能推动组件库的进一步迭代，形成良性循环。

参考资料

 点击阅读原文，快来加入我们吧！