TS 마이그레이션 이전에..
이전에 디자인 패턴의 대한 고민과 redux-saga에서 react-query로 리팩터링의 대한 글을 올렸었는데요. 이 모든 리팩터링 과정은 타입스크립트 마이그레이션 전에 적용되어야 할 우선순위였습니다.
최종적으로 목표는 타입스크립트 마이그레이션이였고, 원할한 TS 마이그레이션을 위해 디자인 패턴을 바꾸어 필요없는 파일은 줄이 redux-saga로 관리되던 비동기 코드들은 react-query로 전환하여 원하는 기능들을 더 편리하게 사용하게끔 만들었습니다.
이렇게 타입스크립트를 위한 빌드업은 끝났고, 타입스크립트 마이그레이션을 하게 되었는데 결코 쉽지 않았습니다. 백엔드분들이 IDC에서 NCP로 이전을 해야되는 상황이였기 때문에 api작업은 원할하게 진행될 수 없던 상황이였고 프론트엔드는 api가 필요없는 UI/UX 개선과 리팩터링을 동시에 진행해야 했기 때문에 브런치를 옮겨가며 열심히 작업했던 것 같습니다.
그럼 Why? 왜 타입스크립트를 도입하게 되었나?
사실 리팩터링과 TS 마이그레이션은 제가 먼저 제안했고, 정말 하고 싶었습니다. 제가 프로젝트를 처음부터 빌드업한 것도 아니였고 어쩔 수 없이 전임자 분들의 코드에 맞춰나가야 하는 상황들과 제가 느끼기에 불편했던 점들이 많았기 때문에 리팩터링과 TS 마이그레이션에 대한 생각은 항상 가지고 있었습니다. 실제로 전임자 분들중에 한분이 프로젝트를 정말 대충 작업했다며 사과하면서 퇴사하기도 하셨죠..
마침 저랑 같이 입사했던 동기는 퇴사하고 새로운 프론트 한분이 합류한 상황에서 그 분과 합을 맞춰나가야 하는 상황이였고, 제가 느끼는 불편한 점들을 똑같이 느끼고 계셨기 때문에 더욱 생각이 확고해졌었죠. 심지어 새로 합류한 분은 타입스크립트를 경험한 분이셨기 때문에 저에게 TS의 대한 장점들을 막 얘기해주셨었습니다. ㅎㅎㅎ
즉, API 작업을 할 수 없는 지금이 기회였고, 그럴려면 시간이 필요했습니다.
그 시간을 따내기 위해서는 맹목적으로 리팩터링만 진행한다고 하는 것은 시간을 따낼 수 없단 생각에 리팩터링을 진행하면서 UI/UX 개선을 같이 하겠다라고 제안하여 시간을 벌 수 있었습니다.
그리고 TS를 도입하기 위한 이유는 명확했습니다.
클라이언트는 JS 어드민은 TS인 상황에서 모든 언어를 TS로 맞추고 좀 더 안정성 있는 프로젝트를 진행할 수 있으니까요. 게다가 이제는 타입스크립트 생태계가 너무 많이 좋아지기도 하였구요.
https://velog.io/@teo/typescript
특히 이 글을 읽고, 더 마음이 불탔던 것도 같습니다.
그래서 TS를 마이그레이션하는 과정과 부딪히면서 제가 깨달았던 TS 지식들을 정리해보려고 합니다.
누군가에겐 이미 알고 있는 얘기일수도, 당연한 얘기일 수도 있지만 혹여나 타입스크립트 도입을 망설여 하시는 분들이나 이제 타입스크립트를 배우시려고 하시는 분들에게 도움이 될 수 있지 않을까 하는 마음과 저 스스로도 한 번 되짚어 보면서 마무리를 하려고 합니다.
타입스크립트 마이그레이션 자체만을 놓고 본다면 정말 어렵나? 그건 아닙니다. 어떻게든 마이그레이션은 할 수 있습니다. 과감하게 any로 넘어갈 건 넘어갈 수도 있고 tsconfig 설정을 바꿔가면서 도입할 수도 있습니다. 그러나 저희는 가능하다면 바꾸고 싶은 구조나 설계의 대해서 고민하고 좀 더 가독성 있게 바꿀 수 있는 것들은 바꿔나가고 싶었기 때문에 시간이 더 걸렸던 것 같습니다. 백프로 만족할 순 없듯이 아쉬운 부분은 당연히 있지만요.
그럼 TS를 마이그레이션을 해볼까요?
TS 세팅
세팅은 크게 뭐 없긴 합니다. 필요한 패키지들을 설치하면 끝입니다.
jsconfig.json에서 tsconfig.json으로 바꿔주고 필요한 옵션들을 지정하여 설정을 맞춰주면 됩니다.
(tsconfig.json은 타입스크립트를 설치하고 tsc --init 명령어를 입력하면 파일이 자동 생성됩니다.)
ts를 도입하기전에 tsconfig 설정을 어떻게 할거며 어떤식으로 코드 컨벤션은 맞춰나갈지 산정회의를 거쳤습니다.
산정회의를 마치고 나서 필요한 패키지들을 설치했습니다.
npm install —dev typescript @types/node @types/react @types/react-dom @types/lodash
가장 기본적으로 이렇게 설치하고, 라이브러리를 사용하면서 필요한 types들은 그 때 그 때 찾아서 설치를 했던 것 같습니다.
(ex: swiper, slick, styled-component 등)
그리고 Typescript 전환은 api, react-query 등 네트워크 요청의 대한 파일들에 대해서 먼저 진행하기로 하였습니다. 어찌됐든 서버에서 넘어오는 데이터가 근간이 되어야 한다고 생각했습니다. 그리고 점진적으로 전역적으로 사용되는 utils, constant순으로 전환하며 최종적으로 컴포넌트까지 마무리 하기로 얘기가 되었습니다.
가장 기본적이지만 API 작업을 하면서 타입 Api Response나 Request는 무조건 서버랑 맞춰줘야 합니다. 이 부분 놓치지 마시구요!
그리고 typescript eslint를 꼭 설치해서 작업하시길 권장합니다.
처음 타입스크립트를 도입하고 나서, 타입스크립트 문법(key in, key of 등)을 사용하였는데 자꾸 빨간줄이 떠서 왜이러지? 하고 찾아봤는데 typescript eslint 설정이 안되어 있어서 빨간줄이 떴었습니다.
이렇게 타입스크립트를 마이그레이션 하게 된 배경과 간단한 세팅을 정리해봤고 다음 포스트에선 제가 깨달았던 TS 지식에 대해 적어보겠습니다!!
'개발일지' 카테고리의 다른 글
웹뷰 및 인앱 브라우저 환경 고려하기 (WebView, in-app) 2 (0) | 2022.06.15 |
---|---|
타입스크립트로 마이그레이션 여정기 2 (0) | 2022.05.05 |
redux-saga에서 react-query로 전환하기 2 (0) | 2022.03.02 |
redux-saga에서 react-query로 전환하기 (0) | 2022.02.28 |
2021년 회고 (0) | 2022.01.01 |