[곰곰 다이어리] 리팩토링 중 만난 에러들 : TypeScript의 never[]

들어가기

최근 곰곰 다이어리를 리팩토링을 하고 있다.

 

⭐️ [as is]

JavaScript, 스타일링: css module, 전역 상태 관리: recoil

 

🌟 [to be]

TypeScript, 스타일링: Styled components, 전역 상태 관리: jotai + tanstack Query

 

사실 신규 기술의 도입을 위해서가 아니라 기존 코드를 뜯어 고칠 게 너무 많아서 시작했는데,

하는 김에 그냥 다 고쳐 버리는 게 좋을 것 같아 전부터 조금씩 하다 요 며칠 불이 붙었다.

 

이렇게 고치게 된 경위는 다음과 같다.

• 기존 코드에서 UI / 비즈니스 로직 분리가 하나도 되지 않음
• 커스텀 훅을 거의 도입하지 않아 코드가 300줄(;)이 넘는 경우가 많음
• 의미가 모호한 변수, 오타, 실제로 사용하지 않는 스타일링 코드들이 발견됨
• 기존에 사용하던 recoil이 지속 가능한지에 대한 의구심
• 클라이언트 상태와 서버 상태가 복잡하게 혼용되고 있음

7월인가 8월쯤에 트래픽이 대거 몰렸고 그 때 마주하게 된 버그를 해결하는 과정에서

내 코드를 파악하기가 쉽지 않아 빨리 대처를 하지 못한 게 좀 충격적이었다.

 

아무리 개발을 못해도 내가 짠 것도 못 알아볼 정도라니... 

물론 규모가 커지면 그럴 순 있겠지만, 그렇게 큰 규모도 아닌데...

클린 코드라는 개념을 나와는 먼 것으로만 여겼던 안일함에 부끄러움을 느꼈다.

 

그래서 빨리 고쳐야지 고쳐야지 했는데, 리팩토링은 정말 쉽게 손이 가지 않더라 🥹

더 이상 미룰 수 없다 나의 코드 나의 리팩토링!

 

아예 싹 고치면서 디자인도 조금 더 손보고, 로띠도 넣을 수 있는 곳에 넣어보고...

익숙하지 않은 TypeScript로 시행착오도 겪어보고 최적화도 더 해보자.

 

그 과정에서 만난 크고 작은 새로 배운 점들, 잊고 있었던 것들을 정리한다.

엊그제부터 이미 좀 많이 고쳐서 시간 순은 아니지만 어쨌거나 기록 기록 📝

 

타입 추론이 되지 않는 배열

TypeScript는 알아서 타입을 추론하기 때문에 구태여 타입을 명시할 필요가 없다고 배웠다.

실제로도 타입 추론이 잘 되기 때문에 딱히 명시한 적이 몇 없는데...

 

[상황]

• responseArr 는 jotai로 관리하는 전역 상태로 type은 Array다.
• 유저가 문항에 답할 때마다 responseArr에 response라는 문자열을 얕은 복사로 추가해준다.

[문제]

setResponseArr([...responseArr, response]);

import { atom } from 'jotai';

export const responseArrAtom = atom([]);

 

Type 'string' is not assignable to type 'never'.ts(2322)

const responseArr: never[]

 

첫 번째 코드와 같이 responseArr에 배열을 넣어주려는데 responseArr가 never[]라고 한다.

 

[원인 및 해결]

• TypeScript가 responseArr의 타입을 올바르게 추론하지 못하고 있다.
• jotai의 atom 초기값으로 []을 사용할 때 타입 정보를 명시하지 않으면 기본적으로 타입을 never[]로 추론한다.

• 빈 배열에는 아무 값도 없기 때문에 해당 배열이 어떤 타입의 요소를 가질지 알 수 없기 때문이다.
• never는 절대 발생할 수 없는 타입으로 이 경우 해당 배열에 어떤 값도 추가할 수 없다.
• 상태 관리 라이브러리에서는 상태의 일관성을 유지하기 위해 초기값의 타입이 명확해야 한다.