이전의 프로젝트를 진행하며 인터페이스 네이밍 규칙으로 다른 변수명과의 구별을 위해 접두사 I를 붙이는 헝가리안 네이밍을 사용했었다. 그러나 MS의 Typescript Coding guidelines에 접두사 I를 사용하지 말라는 규칙이 있는 것을 보고 이에 대해 고민해보게 됐다. (참고로 MS의 가이드라인은 타입스크립트 규정은 아니니 반드시 따를 필요는 없다. 그러나 참고용으로 굿굿) Coding guidelines TypeScript is a superset of JavaScript that compiles to clean JavaScript output. - microsoft/TypeScript github.com Typescript에서 I 표기를 지양하는 이유? 1. 더 이상 변수명으로 역할을 구분..
인터페이스
기존 서비스의 기능 및 페이지를 확장하게 되며, 타입스크립트 정의 방법에 대해 고민을 하게 됐다. 기존에는 서비스 규모가 작았기 때문에 declare로 타입 인터페이스를 정의해두었는데, 이번에 확장하며 필요한 인터페이스의 개수가 많아졌다. 그래서 declare과 export(모듈화) 방식의 성능 차이나 장단점을 알아봤다. 1. 전역적으로 선언하는 경우 (declare) 장점: 편리하게 전역적으로 사용 가능 (별도의 Import 문이 필요하지 않음) 일부 라이브러리와 외부 모듈과의 통합이 간편할 수 있음 단점: 전역 네임스페이스 오염 위험 코드가 커질수록 유지보수가 어려워짐 성능 저하의 가능성이 있음 (일반적으로 미미함) 2. 모듈화된 인터페이스 사용하는 경우 (export) 장점: 네임스페이스 충돌과 오..