过于ts的ts不是好ts

最近独立完成了一个比较大的需求对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固然可以是开发更便捷但是我们在业务、逻辑、数据流上的能力才是真正的开发利器