ProComponents 的理念

1,874 阅读4分钟

Ant Design 定义了基础的设计规范,对应也提供了大量的基础组件。但是对于中后台类应用,我们希望提供更高程度的抽象,提供更上层的设计规范,并且对应提供相应的组件使得开发者可以快速搭建出高质量的页面。

在 ProComponents 中我们内置了一系列的设计规范,预设了常用的逻辑。在这个基础上我们同样提供了灵活的支持,比如对于 ProTable 来说你也可以把它完全当做 Ant Design 的 Table 来用,对于 ProForm 来说你也可以直接使用 Ant Design 的基础组件或者你的自定义组件。我们希望通过 Pro 系列组件提供快速高效大家高质量中后台应用的能力,进一步扩展 Ant Design 的能力,欢迎使用并提出宝贵的意见。

设计思路

对于几乎所有的业务来说,我们做的其实就是根据一个状态定义一系列的行为,以上面的 table 为例,首先我们需要一个状态 dataSource 用于存储从服务器请求的数据,为了优化体验,我们还需要一个 loading。于是我们就有了一系列的行为,我们需要先设置 loading=true,然后发起网络请求,网络请求完成之后就 设置 dataSource 为请求回来的数据,loading=false,一个网络请求就完成了,虽然非常简单,但是一个业务系统有相当多的表格,每个表格都定义这么一次,这个工作量就非常大了。

如果要重新请求网络,我们就需要封装一下行为,将以上的行为封装成一个方法,点击一下重新加载数据,如果你有分页,那么就需要新的变量 page,我们在重新请求之前需要去根据需要来判断一下是否将页面重置为第一页,这又引入了一个变量。如果你的表格还要控制每页的数量,那么将会更加繁杂。这种重复性的劳动会浪费掉我们的很多时间。

一个状态加一系列行为

以上的逻辑几乎存在于所有中后台开发中,每增加一个状态我们就需要一系列的行为来进行管理,每个行为如果耦合了太多的状态也会复杂到无以复加。

碰上这种情况,几乎所有程序员都会想办法进行分层,基于同样的思路,ProTable 希望抽象出一层来解决掉复杂状态的问题,table 中最常用的状态就是 loadingdataSource,包括扩展的 page,pageSize 其实都是服务于网络状态,于是 table 抽象出了一个 request 的 api,在其中封装了 loading 和 dataSource 状态以及他们所有的行为,上一页,下一页,重新刷新,修改每页大小等行为。

这种封装模式可以让前端从各种状态管理中脱身出来,专注于业务开发,也不需要 dva,redux 等数据流的方案,更加符合直觉。开发者只需要定义一个状态,重型组件会自动生成一系列行为。

为了渐进式使用我们也提供了与 Ant Design 相同的 api,完全可以降级成为一个 Ant Design 的 table 使用。

一个组件 ≈ 一个页面

重型组件区别于传统组件有个很大的不同,重型组件在抽象时是将其当成一个页面来进行处理,所以 ProTable 会支持网络请求和自动生成查询表单,而 ProLayout 会支持自动生成菜单,两者都基于同样的思想也就是提供页面级别的抽象。

一个列表页应该可以用 ProLayout + ProTable 完成,一个编辑页应该使用 ProLayout + ProForm 完成,详情页可以用 ProLayout + ProDescriptions 完成。 一个页面在开发工程中只需要关注几个重型组件,降低心智负担,专注于更核心的业务逻辑。

设计与样式

在实际开发中我们也经常会碰到一些设计问题,比如经典的按钮应该放在左面还是右面,查询表单怎么布局,日期怎么格式化,数字的对齐问题,在重型组件中都进行了抽象。对于各种行为与样式我们都经过了设计师的讨论与设计,默认好看并且好用。

感觉很棒?立即使用

参与贡献

我们非常欢迎你的贡献,你可以通过以下方式和我们一起共建 🐲 :

  • 在你的公司或个人项目中使用 Ant Design Pro,umi 和 ProComponents。
  • 通过 Issue 报告 bug 或进行咨询。
  • 提交 Pull Request 改进 ProComponents 的代码。