기존 서비스의 기능 및 페이지를 확장하게 되며, 타입스크립트 정의 방법에 대해 고민을 하게 됐다.
기존에는 서비스 규모가 작았기 때문에 declare로 타입 인터페이스를 정의해두었는데, 이번에 확장하며 필요한 인터페이스의 개수가 많아졌다.
그래서 declare과 export(모듈화) 방식의 성능 차이나 장단점을 알아봤다.
1. 전역적으로 선언하는 경우 (declare)
장점:
편리하게 전역적으로 사용 가능 (별도의 Import 문이 필요하지 않음)
일부 라이브러리와 외부 모듈과의 통합이 간편할 수 있음
단점:
전역 네임스페이스 오염 위험
코드가 커질수록 유지보수가 어려워짐
성능 저하의 가능성이 있음 (일반적으로 미미함)
2. 모듈화된 인터페이스 사용하는 경우 (export)
장점:
네임스페이스 충돌과 오염 방지 가능
모듈 간의 의존성을 명확하게 관리할 수 있음
코드가 모듈 단위로 분리되므로 유지보수 용이
단점:
일부 경우에는 상대적으로 번거로울 수 있음
외부 모듈과의 통합이 조금 더 복잡할 수 있음
TypeScript는 컴파일 시간에 타입 정보를 제거하고 JavaScript로 변환하므로, 실행 시간에는 성능에 거의 영향을 미치지 않는다. 따라서 일반적으로 인터페이스를 전역적으로 선언하는 것과 모듈화하는 것의 성능 차이는 미미하다고 한다.
그렇기때문에 프로젝트의 구조나 확장 가능성 등에 따라 인터페이스 정의 방식을 팀적으로 선택하면 될 것 같다.
다만, 가독성과 유지보수성을 고려하여 모듈화된 방식을 선호하는 것이 좋다. 이는 코드의 확장성과 협업에도 긍정적인 영향을 미칠 수 있다.
결과적으로 우리 팀은 페이지별로 파일을 분리하고 모듈화된 방식으로 인터페이스를 정의하여 사용하기로 결정했다.
'Typescript' 카테고리의 다른 글
인덱스 시그니처 (0) | 2024.05.14 |
---|---|
Element implicitly has an 'any' type because expression of type 'string' can't be used to index type (0) | 2024.03.27 |
Type of emit value is always 'any' with new style defineEmits (0) | 2024.03.27 |
Typescript 인터페이스 네이밍 규칙 어떻게 할까? | 접두사 I를 사용하면 안 되는 이유 (1) | 2024.03.27 |
@input event의 타입 (0) | 2024.03.27 |