[RFC] Form.Item 支持 names

[crazyair]

Motivation

RangePicker 的值是 [start, end] 格式，但是接口定义 100% 都是 start, end 2个字段，所以我们 100% 都需要在 onFinish 里将 [start, end] to start, end，对用户使用造成了很大负担。

Detailed design

<Form onFinish={values =>{
         // values.start、values.end
    }}>
    <Form.Item names={['start', 'end']}>
        <RangePicker />
    </Form.Item>
</Form>

Drawbacks

Form.Item 支持 names ，如果内部将 Item 都改成 names 改造会非常多，成本非常大，还没想到一个改造成本低，但是效果好的方案

Alternatives

暂无

Unresolved questions

无

[Wxh16144]

<Form.Item names={['start', 'end']}> 是不是会和 start.end 冲突？

[crazyair]

props 的这个 names，不会冲突，也可以这样写，这样理解了吗 <Form.Item names={[['start'], ['end']]}>

[Wxh16144]

看错了，一个是 name 。 一个是 names

[Wxh16144]

容易看马虎眼

[crazyair]

<Form.Item name={['start', 'end']} mutilple> ？

[mortalYoung]

我认为好像没啥必要。我个人理解在接口请求和 Form 数据之间有一层 convert 是有必要的。这层 convert 可以确保后端给的数据在给 Form 数据赋值的时候会更稳。如果直接让 Form 对接接口请求，后续的后端的数据改动会改到 UI 层的东西。这是不希望出现的现象。最好是把数据的变动这个 effect 局限到 convert 层里做掉。个人偏见

[crazyair]

我认为接口定义需要跟 Form 强关联，后端 api 变了，前端能报错，需要及时改正。之前给 name 加类型校验也是处于这个考虑

[mortalYoung]

就我个人而言，我认为 Form 的渲染是 View 层了，而接口定义会更偏向数据层了。我个人在开发的过程中喜欢把 View 和数据交互分层。所以我更倾向于 Form 和接口定义是解耦的。
至于 Form 的各种校验，我理解是为了校验数据是否出错来为用户做出错误提示，本质上是为了错误提示服务的。真的要做更加偏实践的数据校验得依靠接口来做。0.0

[mortalYoung]

另外，如果后端 API 变了，导致返回的数据结构变了。我个人认为更应该在 convert 层中去做一个页面上的报错。因为我不认为应该把错误数据给到 Form 里，然后让 Form 去报错。0.0

[crazyair]

rc-field-form 支持 names 改造成本太大，基于使用场景，只需要达到一下 3 个值的处理，即可使用，于是增加 #48488

1. 给到 children 的 value
2. 给到 form 的 value
3. validate 的 value