Form.Item 的双向翻译官：getValueFromEvent 与 getValueProps

当你的表单想存「对象」，控件只想认「ID」时，这两个 API 就是你的救命稻草。

一个尴尬的处境

你有没有遇到过这种场景：后端接口要的是 { id, name, email }[] 这种完整对象，而 Ant Design 的 Select 多选时，onChange 甩给你的却是 ['id1', 'id2'] 这种「光秃秃」的 ID 数组？

你心里可能在呐喊：「我就想要个 name 和 email，怎么就这么难！」

别急，Form.Item 早就料到了这种「表单与控件价值观不一致」的场面，于是派出了两位「翻译官」——getValueFromEvent 和 getValueProps。

getValueFromEvent：从控件到表单的「入关翻译」

职责：控件 onChange 时拿到的原始值 → 转换成表单要存储的值。

想象一下：用户在下拉框里勾选了几个邮箱，Select 一激动，把 ['abc123', 'def456'] 塞进了 onChange。但你的表单是个讲究人，它只想存：

;[
  { id: 'abc123', name: '张三', email: 'zhangsan@example.com' },
  { id: 'def456', name: '李四', email: 'lisi@example.com' },
]

这时候，getValueFromEvent 就该上场了：

<Form.Item
  name="emailList"
  getValueFromEvent={(ids: string[]) =>
    ids.map(id => {
      const opt = emailListOptions.find(o => o.value === id)
      return { id, name: opt?.name ?? '', email: opt?.email ?? '' }
    })
  }
>
  <Select mode="multiple" options={emailListOptions} />
</Form.Item>

流程：用户选人 → Select 吐出 ['id1', 'id2'] → getValueFromEvent 查表补全 → 表单美滋滋地存下 [{ id, name, email }, ...]。

说白了：控件说什么语言，它就翻译成表单听得懂的语言。

getValueProps：从表单到控件的「出关翻译」

职责：表单存储的值 → 转换成控件需要的 props。

问题来了：表单里存的是对象数组，Select 可不管这些，它只认 value={['id1', 'id2']}。你要是直接把 [{ id, name, email }, ...] 塞给它，它能给你整出各种幺蛾子（比如不显示、报错、怀疑人生）。

所以需要「反方向」的翻译：

<Form.Item
  name="emailList"
  getValueProps={(v: any) => ({
    value: Array.isArray(v) ? v.map((x: any) => (typeof x === 'object' ? x?.id : x)) : [],
  })}
>
  <Select mode="multiple" options={emailListOptions} />
</Form.Item>

流程：表单里是 [{ id, name, email }, ...] → getValueProps 抽出 id → Select 收到 value={['id1', 'id2']} → 正常渲染，岁月静好。

总结：表单存什么格式，它就翻译成控件能接受的格式。

俩人配合，天下无敌

getValueFromEvent 控件 → 表单海关入境：把「外来人口」（控件事件）登记成「常住人口」（表单存储） getValueProps 表单 → 控件海关出境：把「常住人口」的信息摘出来，做成「通行证」（控件 props）

方法	翻译方向	通俗比喻

一个管「写进去」，一个管「读出来」，一进一出，完美闭环。

为什么需要它俩？

常规情况下，Form.Item 会把 value 直接传给子控件，子控件的 onChange 返回值直接写回表单。前提是：表单和控件对「值」的理解一致。

一旦出现这种「你想存 A，它只想收 B」的情况，就需要中间层做转换。getValueFromEvent 和 getValueProps 就是这个中间层——既不逼表单迁就控件，也不逼控件理解表单，各说各话，翻译官搞定。

常见使用场景

Select 多选：表单存 { id, label }[]，Select 用 value: string[]
自定义组件：你的组件内部用 { x, y }，表单想存 "x,y" 字符串
日期范围：控件是 [dayjs, dayjs]，表单要 ['2024-01-01', '2024-01-31']
任何「表单存储格式 ≠ 控件内部格式」的组合

边界在哪？什么时候该用，什么时候不该用

既然这两个 API 这么好使，能不能把所有「表单 → 接口」的转换都塞进去，顺便把提交前的 buildPayload、formatRequest 之类的函数干掉？

结论先说：不能。这俩翻译官能力再强，也管不了下面这些事儿。

适合交给它俩的：单字段、控件 ↔ 表单的形状转换

比如选人场景：控件给你 ['id1', 'id2']，表单想存 [{ id, name, email }, ...]。一个 Form.Item、不依赖别的字段，这种用 getValueFromEvent / getValueProps 最合适。

不适合的：跨字段逻辑

比如「配送方式」选「次日达」时，需要传 expectedDate；选「立即配送」时，需要传 pickupTime。最终 payload 长什么样，取决于多个字段的组合，而不是某一个控件自己说了算。

// 伪代码：根据配送方式决定要传哪些字段
if (deliveryType === 'next_day') {
  payload.expectedDate = formValues.date
} else if (deliveryType === 'instant') {
  payload.pickupTime = formValues.time
}

这种「先看 A 字段，再决定 B 字段要不要、长什么样」的逻辑，单个 Form.Item 的转换函数搞不定——它只能看到自己那一亩三分地。

不适合的：多数据源合并

提交时往往要把「主表单」和「别处填的数据」拼成一条请求。比如主表在页面上，附加配置在弹窗里、或来自另一个步骤、或从接口预加载的。这些数据根本不是某个控件的 onChange 能代表的，自然也没法塞进 Form.Item 的转换里。

不适合的：按类型的整体映射

比如「个人注册」和「企业注册」的表单结构完全不同，接口却要求按 type 分别转换成不同的结构再合并。这是「整块配置 → 整块 API 结构」的转换，不是「某个控件值长什么样」的问题。硬塞进 Form.Item，每个控件都得知道全局业务逻辑，维护成本会爆表。

不适合的：字段名不一致

表单里叫 maxRetryCount（业务语义清晰），接口要 retryLimit。理论上可以让 Form 直接存 retryLimit，但这样表单和接口就强耦合了，改接口字段名就得改表单，语义也会变怪。

小结：各司其职

getValueFromEvent / getValueProps：管「控件 ↔ 表单」这一层，单字段值形状的转换。
build 层：管「表单 + 多源数据 → 接口 payload」这一层，跨字段、合并、条件结构、字段名映射。

两者分工不同，谁也替不了谁。翻译官再能干，也当不了整条流水线的总调度。

小结

getValueFromEvent 和 getValueProps 就像 Form.Item 请来的两位翻译：一个负责把控件的话翻译给表单听，一个负责把表单的话翻译给控件听。用好了，表单和控件再也不会因为「语言不通」而打架了。

记住口诀：入关靠 Event，出关靠 Props。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

博客园 - 漫思