熟悉 react + antd 生态圈的朋友可能都知道 ProComponents。它是 react 技术栈中高效开发数据管理后台类项目的必不可少的工具。它高度抽象封装，因而功能十分强大，几乎可以覆盖我们日常在做 2B 项目所涉及的 99% 业务场景。但是也同时存在着下面的问题：
- 它的理解成本是很高的。pro-component 作为最上层的应用层，它底下所涉及的抽象层比较多，抽象封装的对象之间的依赖关系也比较复杂。
- 文档工作做得比较差。它的文档写得十分不全面，还有很多未尽事项。比如说，很多组件私底下支持的 prop 属性并没有在一个文档页面去交代，而是散落在不同的页面和文档系统里面，需要你按图索骥式地去探索（你可以通过阅读它的类型系统来感受我这句话的意思）。所以，pro-component 的文档对于新手是十分不友好的。
换个角度来想，人家的「pro-component」中的「pro」可能就是在表达，这个类库是为 antd 生态的资深玩家去使用的。如果你是新手，注定是要痛苦一段时间的。
- API 设计得不够好。通过深入一下 pro-component 的源码，你就会发现，基本上这个类库的 api 系统基本上看不到太多的设计痕迹，主要是靠时间堆叠出来的 - 缺上就加什么。基本上没有一个人在一个比较高的层次去掌控 api 的设计，以便使得 api 系统能做到既简洁又强大。所以，最终出来的效果是：
- 颗粒度很细，api 巨多；
- 不少 api 的名字的语义让人难以理解；
- 不同抽象层或者对象之间存在不少用途基本相同的 api。
上面的基本上都是一些 DX 的问题。从它所提供的功能来看，这些问题是瑕不掩瑜的。从开源的角度来说，pro-component 是底层打工仔的福音。鉴于此，我们还是要客观地要肯定它在 react 生态圈的巨大贡献价值。
为了提高 pro-component 的 DX，本系列从「应用场景 -> 特性要求 -> 特性实现」的角度对 pro-component 的能力进行了梳理。旨在梳理如何使用 pro-component 去实现一些高频的业务场景。而这些业务场景的答案你很难直观地从pro-component 官方文档得到的。
自我梳理是一方面，另外一方面是我也希望能够通过这个系列来帮助开发者开箱即用地使用 pro-component - 你带着问题而来，翻一翻我的文章，带着答案而去。
当前我会先针对 <ProTable>组件的以下特性进行梳理：
- ProTable 如何实现筛选条件跟 url 参数双向同步？
- 如何设置筛选表单字段的初始值？
- 把筛选条件同步到 url 后，假如我需要添加额外的非筛选条件的参数呢，怎么办？
- 如何自定义 valueType？
- .....
大家如果对这个系列感兴趣的话，欢迎把你们的问题写来评论区，以便作为这个系列的内容之一。如果这个系列做得好的话，那么我们可以把它整理成一个静态文档网站，部署到远程，作为官方文档的一个补充。大家各自贡献出自己的力量，一起把这个antd 这个开源生态做强做大。
