타입스크립트 리팩토링을 진행했다. 관련 PR
왜 타입스크립트 리팩토링을 진행하게 되었나면, 기존의 공식의 타입을 선언하는 것이 매우 뒤죽박죽되어 있었기 때문이다.
주로, API 명세를 토대로 타입을 지정한 곳에서 문제점이 있었다.
개발 중에 기능의 구현방식이 바뀌기도 하고 (예를 들어, 마이페이지에서 글을 조회할 때에 카테고리를 정보를 추가적으로 요청하거나)
여러 명이서 동시에 API를 가지고 개발하다 보니 똑같은 값인데도 부르는 이름이 다르거나(글의 생성시간을 createAt 에서 createdAt으로 다르게 생성되어 있거나) 하는 등의 상황들이 존재하였다.
이러한 의해서 명세가 계속해서 바뀌고 응답값의 이름이 바뀌는 등의 일이 빈번하였기에 같은 값을 지니는 변수의 타입에 대해서도 중복적으로 선언하는 등의 일이있었다.
하지만, 어느 새 팀의 기능이 거의 마무리가 되어가고 우리의 명세에 대해서 돌아볼 시간을 가지며 API 명세가 명확해졌다.
이제는, 중복되어 선언되어있는 타입스크립트를 합쳐줄 시간이다.
우리 공식 서비스가 Article과 관련되어 있다보니 주로 Article을 토대로 중복되어 보여지는 값들이 많았다.
그리고 Article 도메인과 관련하여 나올 수 있는 모든 응답값에서 몇가지만 제외하고 사용하는 곳이 대부분이였다.
그래서 Article에 대해서 나올 수 있는 응답값에 대한 타입들을 모아둔 ArticleTotalType을 만들었다.
그리곤 각각의 요청 마다의 응답값에 대해서 Omit을 활용하여 몇 가지만 빼내어서 하는 방식으로 타입을 지정하였다.
리스트로 오는 응답값에 대해서는 리스트 안에 들어가는 하나의 아이템에 대해서 타입을 분리하여 선언하고 List에서 해당 값을 활용하여 값을 선언하였다.
export interface ArticleTotalType {
id: number;
title: string;
tag: string[];
content: string;
category: CategoryType;
createdAt: string;
updatedAt: string;
author: AuthorType;
views: number;
likeCount: number;
commentCount: number;
isAuthor: boolean;
hasVote: boolean;
isLike: boolean;
}
export type DetailArticleResponseType = Omit<ArticleTotalType, 'category' | 'commentCount'>;
export type SingleArticleItemResponseType = Omit<
ArticleTotalType,
'updatedAt' | 'hasVote' | 'isAuthor'
>;
export interface TotalArticleInquiredResponseType {
articles: SingleArticleItemResponseType[];
hasNext: boolean;
}
이번주는 레벨4의 마지막 구간이였다.
2월 부터 시작된 우아한테크코스 이제는 한 달 도 남지 않았다는 사실에 조금 막막하기도 하고 후련하기도 하다.
이제는 본격적으로 이력서와 포트폴리오 등을 써서 제출해야 할 구간이라 다들 바쁘다. 코딩을 할 시간도 별로 없어 이번 주에 페어와 코딩과 관련된 이야기를 많이 진행하지 못한 것 같다.
다음 주는 정말 더 바쁠 것 같아(자소서를 써야 할 때가 왔다!) 아쉽기도 하다.
남은 레벨 5을 무사히 마무리 해서 다들 원하는 데로 풀렸으면 좋겠다.