上一篇:Ant Design 4.0 的一些杂事儿 - Table 篇
是的,趁着手热,于是又开了一篇新的文章,用来讲讲我们在开发 Ant Design 4.0 的 Form 时遇到的一些杂事儿。当然,欢迎使用、吐槽以及贡献到开源项目中来。Ant Design 4.0.0-rc 版本已经发布,我们提供了一套迁移指南和自动化迁移工具(从社区反馈上来看,我相信不少朋友们已经升级体验了~)。
贤良淑德的 Form
我们的 Form 经过长年累月的改进,API 于业务中可以覆盖大部分场景,而一些特殊的需求也可以通过一些特殊的处理方式来搞定(没错,说的就是你!List Field)。因而在很长的一段时间内,Form 只是在样式和 Bug 上进行一些小修小补。
当然了,一个能用的 Form 并不等于是一个好用的 Form。面对“创造高效愉悦的工作体验”的 slogan,我们的 Form 看起来还有更远的路要走。好在开源项目的一大优势就是有着大量的小伙伴们来提 issue。我们在 issue 的宝库中,可以找到一些共同点。从而得知应该如何进行改进~
为什么需要 Form.create ?
一些刚刚接触 React 的同学们,有时候复制示例代码会只拷贝一部分,然后逐渐添加内容,直到了解这些代码的到底是想要干什么。有时候就会遇到复制了代码却不知道为什么 this.props.form
不存在的情况。
当然,你可以不厌其烦的回答说瞧,你漏了一个 Form.create
,你需要了解一下 HOC 是如何工作的,以及 React 的 props
到底是怎么来的。然后再把 issue 关掉。但是如果一个 issue 总是时不时的出现(就像上篇文章里那个 Table fixed column 对不齐的问题一样),那么这就是一个可以让你优化的点~
antd 中通过 Form.create
创建了一个 form context,里面提供一个 getFieldDecorator
方法用于注册字段。 经由该方法调用后包裹的组件会被自动注入 value
和 onChange
属性进行双向绑定,从而简化用户的输入。但是到这里,你会发现一点,虽然 value
和 onChange
不用写了,但是 Form.create
却省不了啊。而且 getFieldDecorator
要不是自动补全单词一点都不好拼啊。况且,对于 antd 不熟悉的人,在经过层层嵌套的 HOC 后,会一脸懵逼的看着这个 form
不知道是哪里来的。
此外,另一个问题是。我们处处可以通过 form.getFieldValue
来进行一些渲染的控制。比如说字段 A 为某些值的时候,显示额外的字段 B,反之显示字段 C。 为了达到这个效果,我们在 Field 每次变更的时候都需要重新渲染整个组件,以达到 getFieldValue
获取了正确的值的需求。 这又导致了巨型表单会出现明显的性能问题(毕竟全都渲染了一遍嘛~)。
这么看来,Form.create
即淘气又割舍不了。
Bug 也是 feature
小淘气一号:initialValue
v3 的版本,有个小淘气叫 initialValue
。如果你“一不小心”将 initialValue
受控并且用户在该输入框也没有输入过任何的值。你会惊喜的发现,这个输入框居然可以跟着 initialValue
一同改变它的值!
是的,它是一个 bug……
然而,开源项目的一个痛点就是由于用户基数众多。你不能够轻易的去改变一个行为。于是,这个 bug 就成了 v3 版本 Form 的 initialValue
的一个 “feature”……
更惨烈的是,用户有时候会发现这个 “feature”不好用,然后再给这个 “feature (bug)”又提交一个 bug……