背景

Antd V5 发布至今，已经带来了诸多灵活性上的优化，目前的定制能力已经远远超过 V4 的程度，但是在想用 antd 来实现一些自定义组件样式上仍然存在较大距离。例如下面这个样式就很难定制出来：

来源：https://twitter.com/Limichange2/status/1825108940528693558/photo/1

所以本 RFC 希望能够讨论一下如何基于现有的主题体系（ antd token+ classNames/styles ）轻松实现上述定制。

先抛砖引玉一下：https://stackblitz.com/edit/react-vnhfmn?file=demo.tsx

上述是基于现有的开放的 token 能力实现的自定义效果，可以说离原图差的非常远，但是这是目前 antd token 体系开放出来的定制极限，更进一步可能就是得进入到覆写样式环节才能达成，那这个就很难受了。

分析

首先介绍下我的自定义逻辑。在 antd v5 现有体系下，我认为最理想的定制方式是通过包裹一个 <ConfigProvider> 实现组件的定制。例如：

  <ConfigProvider
        theme={{
          components: {
            // 定制所有 Notification 的 token
            Notification: {
              colorTextHeading: token.blue,
              colorText: token.colorTextSecondary,
              borderRadiusLG: 12,
              paddingMD: 12,
              marginXS: 0,
              paddingContentHorizontalLG: 12,
              colorBgElevated: `linear-gradient(90deg, ${token.blue1} -50%, ${token.colorBgElevated} 90%)`,
            },
          },
        }}
      >
        {children}
      </ConfigProvider>

这是非常贴合 React Provider 的一种定制思想，且可以做到很好的样式隔离（不包裹 CP 样式就还是原样） 。

但是目前存在的问题有三块：

1. Token 定义模式问题

各个组件暴露出来的 token 不是面向定制做的设计，比如这里所有的间距类token，如果按个测试，根本不知道每个token到底影响的区域是什么。

2. 开放 token 量问题

例如为了完美还原设计稿，还需要调小不少 icon 的尺寸，但在这里并没有给出来 icon 的尺寸定义 token，导致如果要修改可能只能覆写。

3. 变体影响范围

虽然可以通过以下修改实现

colorTextHeading: token.blue,
colorText: token.colorTextSecondary

某个特定状态自定义，但是这样一来就没法改 warning / error / success 的场景，定制度就又非常受限了。

解法思路

针对上述问题，逐一讨论下：

1. Token 定义模式问题： 这个问题可能是相对来说最好解决的，就是将每个组件可以定义的部分，给出明确的修改接口名。但这个是挺需要花时间梳理和敲定的，是个大工程。

2. 开放 token 量问题： 这个问题我认为可能不能通过无限制开放 token 的方式来解决，应该通过 classNames / styles 来实现元素的定制。比如 Notification这个场景，如果能提供 icon 这个 style ，那么也能实现尺寸的快速定制：

<ConfigProvider
        notification={{
          styles: {
            icon: { width: 16, height: 16 },
          },
        }}
        theme={{
          components: {
            Notification: {
              colorTextHeading: token.blue,
              colorText: token.colorTextSecondary,
              borderRadiusLG: 12,
              paddingMD: 24,
              marginXS: 0,
              paddingContentHorizontalLG: 24,
              colorBgElevated: `linear-gradient(90deg, ${token.blue1} -50%, ${token.colorBgElevated} 90%)`,
            },
          },
        }}
>

3. 变体影响范围： 这个问题目前其实通过 classNames 可以一定程度上解决，比如：

const container = css`

.ant-notification-error {
  color: red
}

.ant-notification-warning {
  color: yellow
}
`

<ConfigProvider
        notification={{
          classNames: {
            container:container
          },
        }}
>

但我非常不喜欢这种方案，因为和最早 antd v4 没啥差别，不是好的解决方案。

这部分我认为可能未来的一个方向是参考 tailwindcss 的发展。其实 tailwindcss 用来做组件的人也不少，他们非常容易遇到上述提到的不同变体之间样式踩踏的情况。而后面出现了一个叫 cva （https://cva.style/ ） 的解决方案，从接口来看非常优雅：

const button = cva(["font-semibold", "border", "rounded"], {
  variants: {
    intent: {
      primary: [
        "bg-blue-500",
        "text-white",
        "border-transparent",
        "hover:bg-blue-600",
      ],
      // **or**
      // primary: "bg-blue-500 text-white border-transparent hover:bg-blue-600",
      secondary: [
        "bg-white",
        "text-gray-800",
        "border-gray-400",
        "hover:bg-gray-100",
      ],
    },
    size: {
      small: ["text-sm", "py-1", "px-2"],
      medium: ["text-base", "py-2", "px-4"],
    },
  },
  compoundVariants: [
    {
      intent: "primary",
      size: "medium",
      class: "uppercase",
      // **or** if you're a React.js user, `className` may feel more consistent:
      // className: "uppercase"
    },
  ],
  defaultVariants: {
    intent: "primary",
    size: "medium",
  },
});

cva 通过定义不同变体，每个变体中添加对应的 className 来实现样式的组合。这样一来大大减少了组合维护的重复性。

我觉得我们可以采用类似的思想允许外部传入对应变体的样式/token 来实现相应的自定义，例如：

<ConfigProvider
        theme={{
          components: {
            Notification: {
             variant:{
               status:{
                 error: {
                   colorText: red
                 },
                 success: {
                   colorText: green
                 },
                }
             }
            },
          },
        }}
>

这样一来就可以做到按照变体维度做样式隔离，我觉得这是后续应该发展的方向（其实这个就是当时搞 v5时候提的 stylish 的概念）

最后，虽然当前 ConfigProvider 具备了样式定制的功能，但是定制组件样式的接口分散在各个props中，我们是否应该给一个封装过的组件，将自定义口子收敛到几个更加高层次的口子上？例如：

<ThemeModify
  notification={
     token : {  / ... / }  // 全局 token + 组件 token
     variant : {  } // 变体覆写位置
     styles :  { / ... / } // 元素样式
     classNames: { / ... /} // 元素类名
  }
>
 { ... }
</ThemeModify >

以上，还是一些比较草稿的一些想法，欢迎一起讨论下