表单设计的哲学：为何我们不再用div堆出区间组件？

引言

在实际项目中，我们常常需要设计"区间输入"组件，比如金额区间、数量范围、时间段等。早期的开发习惯是用多个 <input> 包裹在一个 <div> 里，然后靠拼接字段、监听变化、再手动组装数据提交。这种方式虽然「能用」，但从表单组件设计哲学来看，存在很多隐患。

本文将以我们近期在 form-create 表单引擎中落地的一次区间组件封装为例，讲讲我们为什么放弃了传统的 div + 多字段 组合方案，而采用了「单字段组件接管 + 显式映射配置」的思路，并探讨背后的设计逻辑和通用价值。

传统方案：堆字段 vs 控系统

我们先来看一个早期写法：

js 复制代码

{
  type: 'div',
  field: 'amountRange',
  title: '金额区间',
  children: [
    { type: 'input', field: 'amountStart' },
    { type: 'template', template: '~' },
    { type: 'input', field: 'amountEnd' }
  ]
}

这种方式的问题有以下几点：

field 非原子化 ：父级 amountRange 是虚拟字段，form-create 实际不会采集这个值，而是采集了两个内部字段；
值难以统一处理：提交时前端需手动拼接，重置时需手动清空，回显时需手动拆分；
验证难配置：无法对整个"区间"做一个整体的验证（如「起始不能大于结束」）；
组件与配置分离：业务组件逻辑漂浮在渲染之外，增加维护复杂度；
容易误清空或错回显：因为表单模型和 UI 字段映射不统一，表单清空或回填时容易出错。

新设计：单组件接管 + 显式映射

🔧 基础组件设计

我们将区间输入封装为一个原子组件：

js 复制代码

<!-- RangeGroup.vue -->
<template>
  <div class="range-group">
    <a-input v-model="innerValue[0]" style="width: 40%;" />
    <span>~</span>
    <a-input v-model="innerValue[1]" style="width: 40%;" />
    <span>{{ suffix }}</span>
  </div>
</template>

并将其注册到 form-create 中：

js 复制代码

formCreate.component('RangeGroup', RangeGroup);

配置项变为：

js 复制代码

{
  type: 'range',
  field: 'amountRange',
  title: '金额区间',
  component: 'RangeGroup',
  props: {
    suffix: '万元',
  }
}

🔁 配套映射逻辑（rangeFields）

js 复制代码

requestConfig.rangeFields = {
  amountRange: ['amountStart', 'amountEnd'],
};

提交表单时将 amountRange 拆解为 amountStart 和 amountEnd；
回显时将 amountStart 和 amountEnd 聚合成 [start, end]；
不影响表单原有结构；
表单验证可在组件内统一处理。

设计背后的哲学

1. 原子组件优先

每个 field 应对应一个「完整的业务意义」。用 div 包裹多个字段是一种 UI 层次上的合并，却不是数据层级上的统一。原子组件意味着更强的封装性与一致性。

2. 配置驱动

rangeFields 是一种声明式的「字段映射关系」，替代硬编码的拼装与拆解逻辑，让组件更具配置可控性。

3. 数据模型与UI模型解耦

我们不再让 UI 结构决定字段结构，而是通过中间层映射 （如 formTransform / timeFields / rangeFields）桥接组件行为与后端字段需求。

4. 保持 form-create 哲学一致性

form-create 的设计理念是「字段即模型」，不支持虚拟字段的收集。我们尊重框架哲学，从组件层规避对框架机制的破坏。

落地收益

✅ 字段统一管理，避免重复字段名；
✅ 回显、清空、缓存、校验一套体系；
✅ 跨项目复用该组件变得非常轻松；
✅ 与时间字段处理逻辑一致，形成统一策略；
✅ 易于测试和维护。

尾声：一场组件重构带来的思维演进

很多时候，我们习惯"能跑就行"的开发思路，但当项目迭代次数增多、场景变复杂时，底层表单结构的稳定性、可拓展性、数据一致性，都会成为我们不得不重构的动因。

"为什么不这样设计？" 是我们在组件架构中最常提的问题。从 div 到 RangeGroup，看似只是一个小组件的封装，实则是一次从 UI 思维向模型思维的转换。

如你在实际业务中也遇到了类似的区间字段封装难题，或希望你所在的团队也构建出标准化表单体系，不妨试试这套设计思路。欢迎留言交流。