타입스크립트 리팩토링 하기 🔧
타입스크립트 리팩토링을 진행했다. 관련 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;
}
느낀 점 😤
- 이름을 어떻게 해야 좋을까? 🖊️
타입에 대한 이름 컨벤션이 확정이 되지 않았고, 이번 PR을 통해서 이름에 대해서 논의를 진행하고자 하였기에 코드를 작성할 때 고민이 많이 되었었다.
그래서 일단, (어떤 데이터인지 설명) + (비동기 통신 요청 또는 응답에 사용되는 타입인지 기입) + Type 으로 이름 규칙을 정하고 진행하게 되었다.
다른 사람이 우리의 타입을 보았을 때에, 바로 이해할 수 있을 것이가를 보았을 때에 애매한 부분이 있는 것 같다. api의 응답값과 요청값에 대해서 타입입니다. 라고 말을 해야 이해할 수있지 않을까 라는 고민이 든다. 네이밍은 항상 어려운 것 같다. - 생각 보다 헷깔릴 것 같기도 하고...🧐
아무래도 중복되는 타입이 많다보니 Article 도메인에서 나올 수 있는 모든 응답값을 사전에 선언하고 이후의 Article 관련 타입들의 경우 해당 타입에서 Omit을 활용하여 빼오는 방식대로 진행하였다. 그런데, 해당 방식이 항창 개발 중인 서비스에 도입할 수 있을까? 라는 것은 의문이 들었다.
앞서 문제점에서 말했던 것 처럼, 계속해서 변화되는 API 명세의 틈에서 Total로 정의해둔 타입에서의 변동이 전체의 응답값 타입 지정에 영향일 미칠 수 있기에 타입을 사용하는 단에서 에러가 발생할 수 있는 잠재적인 위험이 있을 것 같았다.
그래도 한편으로는, 타입 변동이 있을 때에 전체 타입을 지정해 둔 곳에서 수정하면, 다른 타입들에서는 반영이 쉽다는 점에는 장점이 있을 것 같다.
레벨4의 마지막 🥲
이번주는 레벨4의 마지막 구간이였다.
2월 부터 시작된 우아한테크코스 이제는 한 달 도 남지 않았다는 사실에 조금 막막하기도 하고 후련하기도 하다.
이제는 본격적으로 이력서와 포트폴리오 등을 써서 제출해야 할 구간이라 다들 바쁘다. 코딩을 할 시간도 별로 없어 이번 주에 페어와 코딩과 관련된 이야기를 많이 진행하지 못한 것 같다.
다음 주는 정말 더 바쁠 것 같아(자소서를 써야 할 때가 왔다!) 아쉽기도 하다.
남은 레벨 5을 무사히 마무리 해서 다들 원하는 데로 풀렸으면 좋겠다.
