注：文章转自 蚂蚁金服科技
Ant Design 4.0 发布了，这次带来了哪些重磅的更新？
本次发布了一些重大更新。比如我们添加了暗黑主题，无边框组件，RTL 国际化支持，Table 、Form、Select 等等的组件重做从而大幅提升性能。由于内容非常多 ，避免直接变成发布文档。欢迎移步至语雀查看完整更新：《Ant Design 正式版来了！》
经过多年发展，Ant Design 已经成为一个生态，请介绍下这个生态包括哪些重要成员，生态今后的演进方向是什么？
Ant Design（以下简称 antd） 作为一个设计体系，包含的不仅仅是一个组件库。除了耳熟能详的 Ant Design React 外，还有 Angular 版本的 NG-ZORRO、Ant Desin Mobile、Ant Design Landing、HiTu React，以及来自社区志愿者的 Ant Design Vue。垂直方向开箱即用的中台前端 / 设计解决方案 Ant Design Pro 和对应的区块市场，以及衍生组件库 Pro Layout 和 Pro Table。设计上也提供了非常多的规范文档以及相关的设计资产。
Ant Design 像是一颗树，在其之上开枝散叶非常的有想象空间。未来首先还是会继续基于设计体系进行深耕，其次会跟随相关框架一同进步。同时 Ant Design 还会立足于真实的业务需求，来丰富生态产品。
在从 3.0 到 4.0 的过程中，antd 团队攻克的最大难题是什么？最自豪的新特性是什么？
v4 版本和社区同学一起重构了大量的底层组件，从而大幅提升了组件渲染性能。举个例子，v3 版本中 Form 组件的字段更新会使得整个 Form 重新渲染，这在大型表单中会有严重的性能问题。在 v4 中，Form 只会更新相关的字段组件，从而大大降低了渲染时长。在 Tree、Select、TreeSelect 等组件内置虚拟滚动，从而大幅减少了实际渲染的元素。
说到比较难的，就是这次重构由于支持虚拟滚动，所以需要处理基于虚拟滚动的动画收缩伸展方案。举个例子，Tree 组件在 v3 版本中，缩放可以通过原生的 transition 与 height 来实现收缩伸展效果。但是在虚拟滚动中，每个元素其实是独立的元素，所以缩放时如果要达到和 v3 一致的动画效果，就需要将与之相关的算法自行实现。因而我们将其划分为多个阶段，在不同的阶段处理不同的逻辑，从而组合出支持虚拟滚动的动画实现。具体实现逻辑比较复杂，如果感兴趣可以查看 rc-virtual-list 的相关代码。
antd 在设计上是如何权衡效率、性能 / 体验和质量三者的？
个人角度看，后三者者其实并不矛盾。Ant Design 的组件开发一般有以下几个步骤：
- 设计师设计视觉、交互稿；
- 工程师进行开发；
- Code Review & 设计师评审。
中间每个环节都会认真负责地完成，其中 Code Review 部分也是最漫长的阶段。Code Review 环节会对 API 以及代码实现反复修正，设计与开发者共同参与，从而达到 1 + 1 > 2 的效果。组件的开发并不能一味地追求效率，从设计到实现都需要慢慢打磨。举个例子，Typography 这个组件作为排版组件，看起来非常简单，但是从设计到开发完成前前后后花了一个月的时间，API 经过了反复调整力求以最精简的方式简化开发者的记忆成本，同时也兼顾了拓展性。设计层面也是反复斟酌以达到中英文语境下都有很好的视觉效果。
在 v3 版本中，组件的性能问题主要出在对旧版 IE 的兼容性需求上，因而不少实现只能使用比较黑的方式，下面的问题会提到所以不重复提了。由于 v4 版本 IE 最低兼容版本改成了 IE 11，这些不再是限制，从而使得我们有能力去逐渐更新，更好地提升性能。
在对 IE 的兼容性方面做了一些取舍，原因是什么？兼容 IE 的难点都有哪些？
v3 版本为了兼容旧版 IE，不得不做一些妥协。比如说 flex 布局不能用，我们就用 float 和 table 来搞；不能用 sticky，Table 为了实现固定列不得不额外再渲染一个 Table 达到固定列的效果。最近几年，随着 windows 系统的升级，旧版 IE 的占比已经越来越小。这也是一个契机，让我们在 v4 版本可以舍弃过于陈旧的 IE 版本，从而轻装上阵。
兼容 IE 的难点在于很多行为是非预期的，往往代码没有什么问题，但是页面渲染就是不正常。对于这种情况，就需要做不少的黑科技。比如说让组件强制刷新、使用 IE only 的 css hack 等等。此外前面提到的很多 HTML 新特性在 IE 环境下无法使用，只能自行模拟导致严重的性能损耗。
你认为 antd 目前对 TypeScript 的支持到位了吗？如果还有欠缺，主要在哪些地方，将怎么解决？
在 v3 版本中，我们大量底层组件是通过 js 编写，因而 ts 的类型定义是在 antd 上额外做的，这样的缺点就是和底层的组件并不完全匹配。在 v4 版本中，我们将大量底层组件也转成了 ts 版本，在 antd 端直接使用这些定义，从而避免了过去定义不匹配的情况。当然，这个过程也不是一蹴而就的，还有一分部底层组件还没有完成转，欢迎社区的同学一同帮助让 ts 定义做得更好。
除此之外，我们也遇到一些有趣而恼人的问题——那就是由于 typescript 和 @types/react 本体的升级，导致原本的 ts 定义失效。过去有过一段时间，antd 的 Button 每周都在更新 ts 定义来适配最新的 @types/react。这种情况在所难免，保持更新即可。
在发布公告里专门提到了 @saeedrahimi @shaodahong 两位社区同学的贡献，能否具体介绍下这里面的故事？
@saeedrahimi 同学他为 v4 贡献了全部组件的 RTL 国际化能力，改了数千行代码。这个功能非常大，过一次 PR 可以看到眼花。就这样我们一遍遍地 Review & Update，最终将其实现，中间非常不容易。
@shaodahong 其实在 v3 时就已经是热心志愿者了，在 v4 的发布中，也帮助做了很多的工作，其中兼容包的开发主要是由他完成的。通过兼容包，开发者可以以尽可能小的成本来将 antd 从 v3 升级到 v4。
当然，除了这两位同学外，还有非常多的志愿者参与了 v4 的开发工作。借这个机会，再次向各位志愿者表示感谢！
有部分用户反馈社区反哺困难，源码使用 rc-* 封装实现，导致开发者想帮忙修复 bug 却望而却步，这方面有考虑如何解决吗？antd 团队是怎样看待与社区开发者之间的联系和交互的？
rc 组件的设计思想是简单且灵活，因而它不会对样式有强依赖。而 antd 除了组件功能外，还有着自己的设计体系，所以在 UI Design 上也会更重一些。这种划分，使得如果用户只想用组件的功能却不需要它的样式就可以直接基于 rc 组件进行封装。举个例子，Form 的底层组件 rc-field-form 本身完全不带样式，而在 antd 出则是封装出带样式的 Form 和 Form.Item 且不暴露底层的 Field 组件。其实在 v4 发布前，已经有不少的社区同学基于 rc-field-form 封装出自己的组件了。两者从设计思想上是不同的，因而在未来也不会合并。
从发 PR 角度看，其实不必有太多的心理负担。组件各司其职，不会因为底层多一个 rc 组件库就望而却步。其实从平时的维护看，志愿者给 antd 和 rc 发 PR 的热情是一样的，不存在有 bug 因为在 rc 组件里就修不了的情况。甚至有时候反过来，有的用户只用了 rc 组件，因而给 rc 组件发了很多的 PR 来帮助改进，这也使得这些 PR 同样反哺给了 antd。
后续的版本规划是怎样的？未来还将有哪些值得期待的新特性？
v4 版本在发布后，由于大量组件的重构，主要精力暂时会聚焦于 bug fix 上。待其稳定后，我们会为 React 未来的 Concurrent 模式做好准备。此外，也有计划为了 css in js 做一下调研，以支持动态切换主题的能力。当然，就像刚刚说的，目前的首要任务还是聚焦在 bug fix 上。
作为被广泛使用的前端明星开源项目，你认为 antd 发展至今取得成功的原因是什么？开源这几年最大的收获和教训是什么？
Ant Design 受欢迎离不开社区同学的支持，是大家的认可才使得 Ant Design 能够走到今天。一个开源项目的成活，除了维护者的保持更新外，也需要来自社区的力量。开源界中，你会看到非常多的优秀项目。但是随着时间推移，逐渐不再维护。因而如何保持项目的活力是重中之重。
Ant Design 从 2015 年写下第一行代码至今走过了不少年头。最大的收获就是来自社区同学的帮助，来一起把 Ant Design 打造成一流的前端组件库。而同时作为开源项目，也必须按照开源的方式来公开透明的维护项目。从而不辜负社区同学的信任。
