字段解构功能在复杂需求下的痛点

[liuweiGL]

这是一篇小作文~

[liuweiGL]

场景

假设现在有一个表单：

type IForm = {
  /**
   * 供应商
   */
  supplierId: string
  supplierName: string

  /**
   * 仓库
   */
  cargoId: string
  cargoName: string
}

对应的，供应商从 SupplierPicker 组件中获取：

type ISupplier = {
  id:string
  name: string
}

type SupplierPickerProps = {
  value: ISupplier
  onChange(value:ISupplier) => void
}

仓库从 CargoPicker 组件中获取：

type ICargo = {
  id:string
  name: string
}

type CargoPickerProps = {
  value: ICargo
  onChange(value:ICargo) => void
}

[liuweiGL]

基础需求

1. 供应商跟仓库都使用字段解构功能。
2. 仓库根据供应商是否有值来决定是否启用。
3. 供应商改变时，仓库字段清空

实现

const schema = {
  type: 'object',
  properties: {
    '{id: supplierId, name: supplierName}': {
      type: 'object',
      title: '供应商',
      'x-component': 'SupplierPicker'
    },
    '{id: cargoId, name: cargoId}': {
      type: 'object',
      title: '仓库',
      'x-component': 'CargoPicker',
      'x-reactions': [
        {
          dependencies: ['{id: supplierId, name: supplierName}'],
          fulfill: {
            state: {
              disabled: '{{ !!$deps[0].id }}'
            }
          }
        },
        {
          dependencies: ['{id: supplierId, name: supplierName}'],
          when: '{{ $deps[0].modified }}',
          fulfill: {
            state: {
              value: undefined
            }
          }
        }
      ]
    }
  }
}

总结

1. 字段少的时候代码风格看着好像也能接收
2. 使用字段解构出来的 name 太难维护，容易出 bug
3. name 失去了标识能力，或则说语义极度下降
4. 字段解构跟你跟模板编译功能组合使用的时候有个让人困惑的地方：

  {
    dependencies: ['{id: supplierId, name: supplierName}'],
    fulfill: {
      state: {
        // 这里是写 id 呢，还是 supplierId ？我得测试，然后把规则背下来
        disabled: '{{ !!$deps[0].??? }}'
      }
    }
  }

[liuweiGL]

进阶需求

1. 添加一个合同字段

type IContract = {
  id: string
  code: string
}

type ContractPicker = {
  value: IContract
  onChange: (value: IContract) => void
}

2. 添加一个物资列表字段

type IGoods = {
  id: string
  code: string
}

type GoodsPicker = {
  value: IGoods[]
  onChange: (values: IGoods[]) => void
}

3. 表单模型调整

type IForm = {
  // ...

  contractId: string
  contractName: string

  goodsList: { goodsId: string; goodsName: string }[]
}

4. ContractPicker 需要仓库 id 作为查询条件

5. GoodsPicker 需要 contractId 作为查询条件

6. 仓库 -> 合同 -> 物资列表 每个上游环节变更要重置下游字段以及启用状态保持一致

实现

 {
  properties: {
    '{id: contractId, name: contractName}': {
      type: 'object',
      title: '合同',
      'x-component': 'ContractPicker',
      'x-reactions': [
        {
          dependencies: ['{id: cargoId, name: cargoName}'],
          fulfill: {
            state: {
              disabled: '{{ !!$deps[0].id }}'
            }
          }
        },
        {
          dependencies: ['{id: cargoId, name: cargoName}'],
          when: '{{ $deps[0].modified }}',
          fulfill: {
            state: {
              value: undefined
            }
          }
        }
      ]
    },
    // △：注意这里
    goodsList: {
      type: 'array',
      title: '物资列表',
      'x-component': 'GoodsPicker',
      'x-reactions': [
        {
          dependencies: ['{id: contractId, name: contractName}'],
          fulfill: {
            state: {
              disabled: '{{ !!$deps[0].id }}'
            }
          }
        },
        {
          dependencies: ['{id: contractId, name: contractName}'],
          when: '{{ $deps[0].modified }}',
          fulfill: {
            state: {
              value: undefined
            }
          }
        }
      ]
    },
    // △：注意这里
    goodsListTable: {
      type: 'array',
      title: '',
      'x-component': 'ArrayTable'
    }
  }
}

问题描述

GoodsPicker 是负责选取物资的，然后使用 ArrayTable 展示。这里就引入一个问题，多个 UI 对应一个 Field 时暂时没有好的解决办法。

现在得使用 Effects 进行同步，有点麻烦了，何况业务上还有其他的联动，导致一个字段的 effect 一大坨。

为什么不

如果只是为了解决多个 UI 映射到一个 Field 的问题，可以把 ArrayTable 放到 GoodsPicker 组件里面维护，但是这样又会导致布局问题跟校验问题。

1. 布局问题

希望 label 跟 search icon 在一行，而 table 能单独占满一整行

2. 校验问题

希望校验信息在 search icon 下面，而不是在 table 下方。

希望的功能

多个 UI 能映射到同一个 Field。

总结

1. 随着字段的增大，schema 已经非常不利于阅读了，到处充斥着解构表达式，要找到某个字段困难度上升
2. 拼写导致的 bug 几率上升

[liuweiGL]

综上所述

1. 从 name 中分离字段解构功能，优化字段解构功能跟其他功能组合使用的能力
2. 增强字段的映射能力，而不限于字段解构，比如添加别名模式，提供 UI 跟 Field 多对一的能力。

期望的效果

// 解构模式
const schema1 = {
  type: 'object',
  properties: {
    user: {
      type: 'object',
      alias: '{id: userId, name: userName}'
    }
  }
}

// 别名模式
const schema2 = {
  type: 'object',
  properties: {
    goodsListPicker: {
      type: 'object',
      alias: 'goodsList'
    },
    goodsListTable: {
      type: 'object',
      alias: 'goodsList'
    }
  }
}

实现方式

略

[liuweiGL]

只能把业务中比较好描述的一些业务抽出来，现实系统中的表单关联比这个要复杂更多。如何方便优雅的使用字段解构功能是一个大问题，因为我不但想少干活，还想把他干漂亮 😄

[janryWang]

感觉你的需求可以考虑使用更标准的 #1147

[liuweiGL]

感觉不一样哈，那个主要是 json 片段的复用功能吧？

[janryWang]

对，你不是主要想少写些代码吗？支持片段复用功能会不会好很多

[liuweiGL]

不一样啊，我没有需要复用的 json 片段。

我的主要问题

字段解构

1. 不用字段解构：我需要在 onSubmit 跟 onDetail（详情/编辑时获取到表单数据的事件）的时候手动把表单中的字段转成接口需要的字段。
2. 使用字段解构：和 'x-reactions' 跟 effects 配合使用时代码可读性破坏严重。

字段别名

多 UI 映射到单个 Field 能力缺失。

[janryWang]

还是没懂啥是多UI映射单个字段

[liuweiGL]

先回家吃饭啦。

[liuweiGL]

下面把跟大佬的聊天记录发出来供大家参考。

[liuweiGL]

聊天记录

[liuweiGL]

聊天记录

[liuweiGL]

聊天记录

[liuweiGL]

聊天记录

[liuweiGL]

聊天记录

[MatriXiao88]

@liuweiGL 所以最后是按照作者说的那个办法去搞了么

[liuweiGL]

是的，都放到自定义组件里面处理了。

[liuweiGL]

但如果是简单的项目，我还是喜欢 json-schema 层来支持这个特性，因为维护成本更低一点。

[yuyi919]

可不可以通过多定义几个hidden字段联动赋值来实现解构，让数据可追踪