antd form dependencies无效_Ant Design 4.0 的一些杂事儿 - Form 篇

上一篇：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……