본 포스트는 인프런의 타입스크립트 입문-기초부터 실전까지 강의(링크)를 듣고 정리한 내용입니다.
함수의 return 값이 없는 경우 void 표시
function log(): void { console.log(todoItems); }
object의 경우 구체적으로 속성의 type을 정의
// let todoItems: object[]; let todoItems: { id: number; title: string; done: boolean }[];
- 이전에 단순히 object type이었다면 보다 더 구체적인 속성에 대한 type을 정의
- 해당 변수나 return 값을 참조하는 변수나 함수가 있다면 해당하는 type도 구체적으로 변경
object의 속성들의 구체적인 type(스펙)의 반복 제거
- 앞에서 object의 스펙이 복잡하면 복잡할수록 코드가 지저분해진다.
- 반복이 많으면 많을수록 더 곤란
- 때문에 한 번만 정의하고, 이를 가져다 쓰는 방식
- 깔끔한 코드 및 유지보수, 협업에 유리
interface User { age: number; name: string; } const seho: User = { age: 33, name: '세호' }
function getUser(user: User): void { console.log(user); } getUser(seho);
함수 스펙(구조)에 인터페이스 활용
interface SumFunction { (a: number, b: number): number; } let sum: SumFunction; sum = function(a, b) { return a + b; }
- 함수 인자나 return 값의 type을 interface에 미리 정의
- 함수 선언에서 interface를 지정
- 인자의 수가 적고 구조가 간단한 경우 interface보다는 인자에 바로 지정하는 것을 권장
interface StringArray { [index: number]: string; } const arr: StringArray = ['a', 'b', 'c']; arr[0]; // 'a'
- 인덱스에 숫자 type만 입력하도록 제한
- 인덱싱으로 뽑힌 결과는 문자 type이어야 한다는 의미
interface StringRegexDictionary { [key: string]: RegExp; } const obj: StringRegexDictionary = { // sth: /abc/, cssFile: /\.css$/, // css 확장자를 가지는 모든 파일을 들고오는 정규표현식 jsFile: /\.js$/, }
- RegExp: Regex Expression(정규 표현식)의 약자
- 딕셔너리에서 key의 type은 string, value의 type은 RegExp가 되도록 제한하는 인터페이스
interface Person { name: string; age: number; } // interface Developer { // name: string; // age: number; // language: string; // } interface Developer extends Person { language: string; } const capt: Developer = { name: '캡틴', age: 100, language: '타입스크립트' }
- interface 자식인터페이스 extends 부모인터페이스로 인터페이스 상속
특정 타입이나 인터페이스를 참조할 수 있는 타입 변수
type Todo = { id: string; title: string; done: boolean }; function getTodo(todo: Todo){};
- 복잡한 구조의 type을 마치 하나의 type처럼 취급
- 하지만 새로운 타입값을 생성하는 것은 아님
- 정의한 타입에 대해 나중에 쉽게 참고할 수 있게 이름을 부여*하는 것
- VSC Preview
- interface: interface라는 정보만 확인 가능
- type: 구체적인 내부 속성 type까지 확인 가능
- 확장성
- interface: 확장 가능(extends 등)
- type: 확장 불가능
- 때문에 interface가 더 유리
- 좋은 소프트웨어는 언제가 확장이 용이해야 한다는 원칙
