最近独立完成了一个比较大的需求 对ts有了更深入的理解
我司的代码类型错误不少 红线扎堆 我也一度以为类型写的好 编码没烦恼
因此 在接到需求以后 我立刻开始了类型定义
ts
type Agent = AgentBasic & xxx & AgentType
type AgentBasic = xxx
// xxx
type AgentType = AgentType1 | AgentType2
type AgentType1 = {
type: 'value1'
valueArray: {
name:number
value:string
}[]
}
type AgentType2 = {
type: 'value2'
key: string
}
这个场景很常见 就是同一大类型不同小类型的对象 会携带不同独特数据
不过这种类型体系很快就让我遇到了问题
- 首先是 antd的Form.Item组件
AgentType1
的valueArray
不会出现在name的备选项中 - 其次 取用其中的类型非常不方便 很多地方都需要写Extract<Agent,'xx'> 如果是可选属性还要再加个NonNullable
- 第三 很多时候需要在setState的时候 重复判断一次类型 非常烦
- 最后 用户可以自由编辑valueArray的子项以及它们的name和value 并且在另一个地方响应式的使用
为了唯一标识数组项 每当用户添加一项数据时 我都要为这个子项增加一个key属性
那么 表单的类型该怎么写呢? 把 type Agent从头到尾写一次吗?
ts
type FormAgentType2 = Omit<AgentType2,'valueArray'> & {
valueArray: (AgentType2['valueArray'][number] & {key:string})[]
}
type FormAgent = AgentBasic & xxx & (AgentType1 | AgentType2)
太复杂了。或许取个巧?
ts
type FormAgent = Agent & {
valueArray: (AgentType2['valueArray'][number] & {key:string})[]
}
不过很可惜 这种方法是错的 FormAgent['type'] 只有value1一个选项了
通过type可以筛选额外属性 通过额外属性自然也可以筛选type 非常合理
所以可以得出结论 这种符合实际类型的type不一定是开发所需要的
对于我所面对的场景 这样的类型定义显然更合适
ts
type Agent = {
// xxx
type: 'value1'|'value2'
/** type='value1'时 */
valueArray: {
name:number
value:string
}[]
/** type='value2'时 */
key: string
}
连问号也不需要 避免后期使用NonNullable
类型系统是为开发服务的 过度追求类型完善只会误入歧途
ts固然可以是开发更便捷 但是我们在业务、逻辑、数据流上的能力才是真正的开发利器