[Field]优化 Field 类型注释

[xxih]

Component

Field

Feature Description

  const field = Field.useField<{
    schemaName: string;
    tableName: string;
    comment: string;
    owner: string;
  }>({
    autoUnmount: false,
    values: {},
  });

希望支持这样的泛型写法，能使得 field 使用过程中有更好的类型提示。

[github-actions]

这是您为 Fusion/Next 提的第一个 issue，感谢您对 Fusion 的信任和支持，我们会尽快进行处理。

[xxih]

我在个人项目中对 Field 做了一层封装，重写了类型注释。可提供更好的类型提示，供参考交流

demo.txt
type.txt

[eternalsky]

field 的 values 值是动态化的，如果只是在初始化的时候传入类型，后续动态 set 之后就对不上了。

[eternalsky]

目前在 getValues 的时候是提供泛型支持的。如果需要做 values 的类型校验，可以用 getValues 的

[xxih]

目前在 getValues 的时候是提供泛型支持的。如果需要做 values 的类型校验，可以用 getValues 的

我推崇的这种写法，有几个好处

1. 类型定义在源头，可以减少冗余
   比如，只需要在一个地方定义，调用实例方法都不必再写类型定义。不止于 getValues ，多个方法都可以获得良好的类型提示
   如 getValue

如 `init` 甚至 `validator`

2. 能够极大地提升开发体验
   不需要再翻阅代码，到处找这个 Field 里面有什么字段，找这个字段是什么类型。尤其是有的代码，将 Field 往下传，这个时候里面有什么字段，已经不受控制了。

从使用 Field 的开发人员的视角来看，目前的 Field 类型定义不好用，是比较落后的。我认为开发人员会更喜欢上文提供的这种类型定义方式。

3. 起到约束作用，能够促使用户写出更可维护的代码
   TS 一大作用是能够约束不合理的行为。从源头为 Field 定义类型，不只是 getValue 、getValues 时能获取到期望的类型。还能够在写出不合理 init 的时候给出提示。

实际开发中有一个问题是，不少代码会将 field 层层嵌套传递，最终很难知道这个field 里究竟有哪些字段。支持在源头约束类型，可以迫使开发者在源头处定义好 Field，下游只是是消费者，代码会更好维护。

PS: 我认为 Field 是一个集中管理多个字段的 store。那么这个store 存储的 key、值类型，应该也需要被集中统一管理。而不是 Field 一旦被传递到下层组件，就失去控制了。当然也可以在业务代码中自行封装，但我觉得 Field 本身可以做得更好。

[xxih]

field 的 values 值是动态化的，如果只是在初始化的时候传入类型，后续动态 set 之后就对不上了。

你说的这种场景，使用联合类型

const field = ExField.useField<{
  schemaName?: string | number;
}>({
  autoUnmount: false,
  values: {},
});