ts

124 阅读3分钟

本文章是我在团队日常开发中发现的一些问题的总结,有不对的地方欢迎大家指出,互相学习、共同进步~~

类型不会复用

在日常开发中,一般我们对于每个接口都要定义好请求参数的类型和返回参数的类型。而对于一些比较常见的功能,我们一般会有固定的参数和一些固定的返回字段。

例如列表接口,我们一定会带上page和rows,这个时候我们就可以先写一个基础的列表请求类型如:

ts
 代码解读
复制代码
interface ReqPage {
  current?: number;
  size?: number;
}

这样在后续其他列表的请求参数,我们在定义的时候就可以继承这个ReqPage去复用。 假设我们现在有一个UserList接口,我们定义请求参数的类型就可以这样写:

ts
 代码解读
复制代码
interface UserListParams extends ReqPage {
  name: string;
  id: string | number;
}

另外对象类型也有喜欢用type定义的小伙伴,那么对于type我们同样可以复用,但是形式上稍微有点不同,还是上面的例子

ts
 代码解读
复制代码
type ReqPage =  { current?: number; size?: number };

type UserListParams = { 
    name: string;
    id: string | number;
} & ReqPage

对于返回参数的类型定义也一样,后端接口一般有几个字段例如creatTime, updateTime等是必定返回的,我们可以提前定义一个基类用于其他返回类型去继承复用。

不会使用工具类型

TypeScipt内部提供了很多工具类型如:PartialPickExcludeOmit

举个在日常工作中经常遇到的例子,还是后台管理系统中常见的列表功能。一般我们的表格会有一些搜索字段,这个时候我们就可以用上我们的工具类型了

ts
 代码解读
复制代码
假如我们现在有一个用户列表,他的返回格式如下:

interface ResUser {
    name: string;
    id: string | number;
    age: number;
    grade: number;
}

如果我们要将name作为搜索条件,那么你的请求参数类型应该怎么定义呢?我们可以使用工具类: Pick 或者 Exclude

type ReqUser = Pick<ResUser, "name"> & ReqPage;

如果搜索条件的字段较多的时候我们就可以考虑使用Exclude方法

个人认为使用工具类有两个好处:

  1. 将两个有关联的类型关联起来,而不是凭空创造一个新的类型。让团队中的其他人知道她们是属于一个功能模块的。
  2. 增加复用性,而不是单纯的copy yourself

不会使用泛型

还是上面列表接口的例子,我们一般列表分页接口的返回会包含几个通用的字段,例如: records-当前页数的数据, total-总页数, pages-总页数等等。但是对于不同的接口我们所需要定义的类型是肯定不一样的,就是说records对应的类型肯定是不同的。

这时候就有小伙伴想起上面的复用了。但是除此之外我们还有更好的方法实现-就是泛型

ts
 代码解读
复制代码
// 分页响应参数
interface ResPage<T> {
  records: T[];
  current: number;
  size: number;
  total: number;
}

作者:迷途小学生
链接:juejin.cn/post/743988…
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。