ant-design
建议统一组件相关 API 设计，提升 Ant Design 的一致性
问题描述
在使用 Ant Design 的过程中，发现多个组件的方向控制API及属性命名存在不一致性，这可能导致开发者学习和使用成本增加和代码维护复杂度上升。
就像官方把一些组件的打开和关闭都统一使用 open 和 close，很好，但对于其他的属性优化不够彻底。
理想状态是，只要学会了一个相对属性较多的组件，其他的组件基本属性也掌握个差不多了。
以下是具体问题分析：
一、方向控制属性命名与类型不统一
1. 基础方向控制属性对比
| 组件名称 | 当前属性名 | 当前取值 | 问题分析 |
|---|---|---|---|
| Divider | type |
horizontal | vertical |
type 语义和表现不一致，未明确表示方向控制 |
| Flex | vertical |
boolean |
与其他组件的方向控制属性名不一致 |
| Space | direction |
vertical | horizontal |
与其他组件的方向控制方式不一致 |
| Splitter | layout |
horizontal | vertical |
layout 语义不聚焦于方向控制，到这里，四个组件，同样含义，四种属性 |
| Steps | direction |
vertical | horizontal |
除了属性问题，API文档的说明： 取值顺序与部分组件（如 Divider）不一致 |
| Slider | vertical |
boolean |
与其他组件的方向控制方式不一致 |
| Segmented | vertical |
boolean |
与其他组件的方向控制方式不一致 |
个人更喜欢，
boolean控制，但不十分喜欢vertical或horizontal作为属性名，话虽如此，可我也没有好的建议。
2. 复合属性的职责混淆
| 组件名称 | 当前属性名 | 当前取值 | 问题分析 |
|---|---|---|---|
| Menu | mode |
vertical | horizontal | inline |
混合方向（vertical/horizontal）与布局模式（ inline 可能独立出来更好） |
| Form | layout |
vertical | horizontal | inline |
同样存在方向与布局模式的职责混淆 |
| Tabs | tabPosition |
top | right | bottom | left |
个人认为，首先确认垂直再确认左右， 可能也是拆分比较好，但可能显得有点麻烦，不好确定。 |
二、属性命名的冗余与不一致
1. Tabs组件的前缀冗余问题
- tab里面有很多属性都是tabxxxx，我觉得是否有点多余？
- 我知道加上tab的意义是，知道这是控制tab导航的，如果是这样的话，
hideAdd是不是也得是tabHideAdd，indicator也得是tabIndicator？ - 所以我觉得名称上
tab显得多余，不知道其他的组件还有没有类似的情况，还没有细看。
2. 通用命名冲突
部分组件使用type、mode、direction 和 layout 职责不一致，有的时候：type是方向，有的时候type是类型，有的时候type是模式。
三、其他组件可能还有其他潜在的问题
- 部分组件对垂直/水平方向的控制逻辑不同（如
Flex的vertical为布尔值，而Steps的direction为字符串枚举）。 - 布局相关属性在不同组件中的命名和行为存在差异。
四、总结
当前 Ant Design 的组件API在方向控制、属性命名和语义一致性方面存在较多碎片化问题，建议官方对全量组件的相关属性进行系统性梳理，建立统一的设计规范，以提升框架的易用性和可维护性。
其他组件属性
在后续日常开发中，我会留意这些属性，逐渐补充下方列表。
- 分割线/Divider
感谢您提出关于 Ant Design 组件方向控制 API 设计不一致的问题。您详细分析了多个组件在方向控制属性命名和类型上的不一致性，以及复合属性的职责混淆问题。这些确实可能导致开发者在使用过程中遇到困难，增加学习成本和代码维护的复杂度。
我们会将您的建议记录下来，并在未来的版本中考虑对这些组件的 API 进行统一和优化，以提升框架的一致性和易用性。这需要对现有组件进行全面的审查和设计调整，以确保在不破坏现有功能的情况下实现更一致的 API 设计。
如果您有更多的建议或需要进一步的帮助，请随时在评论中描述您的问题，并 @petercat-assistant 以便与我进行对话交流。
🪧 Tips
For further assistance, please describe your question in the comments and @petercat-assistant to start a conversation with me.![petercat-assistant[bot] avatar](https://avatars.githubusercontent.com/in/875736?v=4 "Published by a pub.dev verified publisher"){kind=small}
Divider 表示分割线标题的位置的属性 orientation 可能不当，因为很多组件 （下面列举一些其他的组件的相关属性） 都是 position 或 xxxPosition 来控制某些元素的位置，到了Divider 却是 orientation，不够统一。
| 组件名称 | 属性名称 |
|---|---|
| Button | iconPosition |
| Carousel | dotPosition |
| Collapse | expandIconPosition |
| Timeline.Items | position |
赞同，每次用 antd 的时候，一些布局相关组件的 prop 没统一，就总是记混，老是得转到类型声明文件里再看一次（另外感觉 antd 的类型注释写的确实不错）
<Space direction="vertical" />
<Space vertical />
看起来 direction 会好一些
- 扩展性会好一些，如果是一个
bool不方便扩展，比如Steps可能会出现diagonal - 语义化也更好一些
看起来 `direction` 会好一些
- 扩展性会好一些，如果是一个
bool不方便扩展，比如Steps可能会出现diagonal- 语义化也更好一些
确实，可能还是 direction 属性更好些。
我补充一个：
<Tooltip title="xxx" />
<Alert message="xxx" />
<Alert.ErrorBoundary message="xxx" />
希望可以把 Alert/Alert.ErrorBoundary 的 message 改成 title。毕竟 Tooltip/Popconfirm/Popover 统一都有 title，所以我经常以为 Alert 的主体内容也是 title
@liuyib 十分认可，
message和其他的组件造成了混乱，每次都是看了文档，才知道具体作用，增加了学习和记忆成本。
很好的建议，v6 已经这么做了~ 做了兼容警告，可以使用 title 来替换。 https://github.com/ant-design/ant-design/pull/52669/files#diff-e7b678382f0c632748d793d3cdbd2207a645522f3a84911e91598381adb6b8d5L115
@liuyib 十分认可，
message和其他的组件造成了混乱，每次都是看了文档，才知道具体作用，增加了学习和记忆成本。很好的建议，v6 已经这么做了~ 做了兼容警告，可以使用 title 来替换。 https://github.com/ant-design/ant-design/pull/52669/files#diff-e7b678382f0c632748d793d3cdbd2207a645522f3a84911e91598381adb6b8d5L115
message => title 后， description 是不是也需要改成 content ？ （感觉 next 分支改动太多，也会让已经习惯 api 的开发者困扰
description => content 合理，但是这一块属于是历史债务，涉及到的不仅仅是一个 content api，还有相关的 design token，以及 dom 上的 className，会要兼容很多代码，并且带来一定的破坏性，不确定收益和牺牲是否值得，如果来得及的话，可能会考虑做。
如果改 alert 组件，那么对应的 notification 的 description 也需要做。
content 和 description 语义是不一样的。
Alert 组件的 description 在使用上和 Modal、Tooltip / Popover / Popconfirm 这些的 content 太接近了，就连 message 也是用 content。
没坐，还有size也有同样的问题,一会是"small" | "large" | "default",一会是"small" | "middle" | "large",一会是'default' | 'small'，二开的时候经常要写这种很多余的判断
