TypeScript 배열 필터링 타입 에러 체크리스트

TypeScript를 쓰는 이유 중 하나가 빌드 타임에 타입 오류를 잡는 것인데, 배열 필터링할 때 타입을 놓치는 경우가 자주 있다. 런타임에는 문제가 안 보이니까 더 위험하다.

필터 함수의 반환 타입부터 확인하기

배열의 filter 메서드는 조건에 맞는 항목들만 새 배열로 반환한다. 이 새 배열의 타입이 원래 배열과 다를 수 있다. 특히 타입 가드를 사용해서 타입을 좁혀야 할 때가 있다.

# TypeScript 컴파일 확인
npx tsc --noEmit

# 빌드 실행
npm run build

null이나 undefined를 필터링할 때 주의하기

배열에 null이나 undefined가 섞여 있으면, 필터링 후에도 타입이 (T | null | undefined)[]일 수 있다. 확실하게 제거하려면 타입 가드를 명시해야 한다.

선택적 속성(optional)이 있으면 더 신경 써야 하기

배열 항목의 속성이 name?: string 같은 선택적 속성이면, 필터링 후에도 여전히 string | undefined일 수 있다. 필터 함수에서 명시적으로 체크해야 타입 좁혀진다.

타입 단언은 마지막 수단으로

빌드 에러를 무시하고 싶어서 as 단언을 쓰는 건 최악이다. 이렇게 하면 TypeScript의 타입 체크 이점이 사라진다. 대신 타입 가드를 제대로 작성해서 에러의 근본 원인을 해결하자.

필터 함수를 따로 정의해서 명확하게 하기

복잡한 필터 조건이 있다면, 필터 함수를 따로 정의해서 타입을 명시하는 게 낫다. 그러면 타입 체크도 정확해지고 재사용도 가능하다.

// 타입 가드 함수
function isValidUser(item: any): item is User {
  return item && typeof item.id === 'number' && typeof item.name === 'string';
}

// 필터링
const validUsers = users.filter(isValidUser);

빌드 실패 메시지를 완전히 읽기

TypeScript 빌드 에러는 보통 어느 파일의 어느 줄인지, 그리고 왜 타입이 맞지 않는지 명확하게 알려준다. 그 메시지를 그냥 복사해서 검색하지 말고, 먼저 자신의 코드와 비교해서 뭐가 빠진 건지 파악하자.