技术

关于Vue3中命名方式问题

最近写了点vue页面，把遇到的问题整理下，免得自己下次再遇到同样问题没有一点印象

第一版 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

// src/api/types/article.ts 接口请求与返回类型
export interface ArticleRequestData {
 /** 当前页码 */
 pageNo: number
 /** 查询条数 */
 pageSize: number
 /** 查询参数：用户mp_id */
 mpId?: string
 /** 查询参数：关键词搜索 */
 searchText?: string
}

export interface ArticleData {
 id: string
 mpId: string
 title: string
 picUrl: boolean
 publishTime: number
 mpName: string
 mpCover: string
}

export type ArticleResponseData = ApiResponseData<{
 list: ArticleData[]
 total: number
}>


// src/views/Article.vue 页面
const tableData = ref<ArticleData[]>([]); // 定义接口返回类型

const getTableData = () => {
 geArticleListApi({
   pageNo: paginationData.currentPage,
   pageSize: 12,
   mpId: searchData.mpId || undefined,
   searchText: searchData.searchText || undefined,
 })
   .then(({ data }) => {
     console.log(data);
     paginationData.total = data.total;
     tableData.value = data.list;
   })
   .catch(() => {
     tableData.value = [];
   })
   .finally(() => {
     loading.value = false;
   });
};

不出意料，后端看着就奇怪了。请求参数都变成小驼峰，最直接的方式需要后端定义的struct中改成小驼峰。

[api/article?pageNo=1&pageSize=12](http://localhost:3334/api/article?pageNo=1&pageSize=12)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

type ArticleListReq struct {
   MpId       string `form:"mpId"`
   SearchText string `form:"searchText"`
   PageNo     int64 `form:"pageNo,default=1"`
   PageSize   int64 `form:"pageSize,default=20"`
}


type Article struct {
   ID          string `json:"id" db:"id"`
   MpId        string `json:"mpId" db:"mp_id"`
   Title       string `json:"title" db:"title"`
   PicUrl      string `json:"picUrl" db:"pic_url"`
   PublishTime int64  `json:"publishTime" db:"publish_time"`
}

第二版 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// src/api/types/article.ts 接口请求与返回类型
export interface ArticleRequestData {
 /** 当前页码 */
 page_no: number
 /** 查询条数 */
 page_size: number
 /** 查询参数：用户mp_id */
 mp_id?: string
 /** 查询参数：关键词搜索 */
 search_text?: string
}

export interface ArticleData {
 id: string
 mp_id: string
 title: string
 pic_url: boolean
 publish_time: number
 mp_name: string
 mp_cover: string
}

export type ArticleResponseData = ApiResponseData<{
 list: ArticleData[]
 total: number
}>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// go 中 请求与返回结构体
type ArticleListReq struct {
   MpId       string `form:"mp_id"`
   SearchText string `form:"search_text"`
   PageNo     int64  `form:"page_no,default=1"`
   PageSize   int64  `form:"page_size,default=20"`
}

type Article struct {
   ID          string `json:"id" db:"id"`
   MpId        string `json:"mp_id" db:"mp_id"`
   Title       string `json:"title" db:"title"`
   PicUrl      string `json:"pic_url" db:"pic_url"`
   PublishTime int64  `json:"publish_time" db:"publish_time"`
}

这样后端看着爽了，保持原来的风格不变。页面中用下划线或小驼峰对我这种业余前端来说无所屌谓，但压倒我的最后一根稻草就是，我后端定义struct。前端又重复一遍interface类型，这不是自己难为自己么？？？如果前端用any，那我还用TS约束啥类型呢？？？越来越纠结。

🤗总结

前端只检查自己负责的类型和后端需要检查的类型，比如前端自己写的逻辑代码、传递给后端接口的参数，后端接口返回的类型为any。

下划线或小驼峰按与谁发生交互命名，比如定义json中使用的就用下划线，其他都用小驼峰。