[네이버테크톡] '무엇이 TS를 TS답게 하는가' 요약 및 정리

* 본 게시글은 NAVER Engineering 채널의 무엇이 TS를 TS답게 하는가 테크톡을 듣고 정리한 글입니다.

 

무엇이 TS를 TS답게 하는가

 

❓ TS를 사용하는 이유

• 컴파일 단계에서 오류를 잡아줌
• 리팩토링이 쉬워짐
• 코드 작성을 편하게 해줌

그렇다면 TS에서는 어떻게 이런 것들이 가능해지는 걸까?

코드는 끊임없이 변하기 때문에 설계와 클린 코드에 신경써야 하고 안정성과 확장성을 확보해야 함

따라서 확장하기 쉬운 설계를 적용하고 IDE가 코드 변화를 추적할 수 있도록 해야함

 

✅ TS 자가검진 척도

• any와 string 타입을 지나치게 사용하는가?
• IDE의 TS 지원 기능을 사용하지 않는가?
• enum 대신 문자열과 매직 넘버를 사용하는가?
• 같은 구조의 인터페이스가 별도로 선언되어 있는가?
• JS에서 사용하던 패턴을 TS에서는 사용할 수 없는가?

 

🛠 IDE 설정

• TS 렌즈 설정
  '참조'를 통해 어디에서 몇 번 사용되고 있는지 확인할 수 있음
  ex. 선언한 타입이 어디에서도 사용되지 않는 경우 삭제 가능

VSCode 설정 화면

TS가 아니더라도 사용되지 않는 함수를 확인하기 용이하다

• VSCode 단축기
  • cmd + . : 자동 수정 / 리팩토링 옵션 열기
  • F2 : 심볼명 바꾸기 (참조하고 있는 심볼명까지 변경됨)
  • cmd + 클릭 : 심볼 선언부 / 사용부 이동
  • cmd + d : 선택한 텍스트와 동일한 텍스트 일괄 변경
  • cmd + shift + o : 파일 내에서 심볼 찾기

 

🧩 enum과 구조체 정의

string을 몰아내자!

 

string을 사용할 경우

1. 오타가 나서 오류가 나기 쉽고
2. 오류를 쉽게 발견할 수 없다

string을 몰아내기 위해

1. generic을 사용하자
2. 구조체의 필드명을 타입으로 사용하자
3. enum을 구조체의 필드명으로 사용하자

 

✏️ 구조체 정의에 string을 사용한 경우

// 객체 및 함수 선언
const father: Father = {
  beauty: "very nice",
  smart: 100,
};

const mother: Mother = {
  brave: "unbelivable",
  healthy: 100,
};

const me: Me = {
  brave: "so so",
  smart: 50,
};

function getAttr(target: any, attrName: string) {
  return target[attrName];
}

// 함수 호출
getAttr(father, "beauty");
getAttr(mother, "brave");
getAttr(me, "smart");

• getAttr()는 target과 attrName을 받아 target의 attribute를 반환하는 함수
• 새 객체에 범용으로 사용하기 위해 target은 any, attrName은 string 타입을 지정

 

✏️ generic을 사용해 함수 선언부 변경

function getAttr<T>(target: T, attrName: keyof T) {
  return target[attrName];
}

• generic을 사용 (TS 도큐먼트)
• target으로 전달 받은 구조체가 가지고 있는 attribute만을 attrName으로 받을 수 있게 되어 string 사용 시 발생할 수 있는 오타로 인한 오류를 방지할 수 있음 (대박 😇)

 

✏️ 함수 호출부에 enum을 사용

// enum 선언
enum AttrType {
  BEAUTY = "beauty",
  BRAVE = "brave",
  SMART = "smart",
  HEALTY = "healty",
}

// 함수 호출부
getAttr(father, AttrType.BEAUTY);
getAttr(mother, AttrType.BRAVE);
getAttr(me, AttrType.SMART);

• enum 선언 후 함수 호출부의 string을 대체

 

✏️ 타입 선언 시 필드명을 enum으로 사용하는 방법

// 타입 정의
type Father = {
  [AttrType.BEAUTY]: string;
  smart: number;
}

 

type Something = {
    [key in AttrType]: string | number;
}

• enum의 모든 값을 필드로 갖는 타입 선언
• 필드 각각의 타입은 선언할 수 없음

 

파생된 구조체 만들기

// 타입 정의
type Father = {
  beauty: string;
  smart: number;
}

type Mother = {
  brave: string;
  healthy: number;
}

type Me = {
  brave: string;
  smart: number;
};

Me 타입은 Father와 Mother로부터 속성을 하나씩 받아온 것인데, 구조를 따로 선언함으로써 이러한 관계가 표현되지 않음

✏️ 교차 타입(Intersection Type) 사용

// 타입 선언
type Me = Father & Mother;

// 객체 선언
const me: Me = {
  brave: "so so",
  smart: 50,
};

• Me 타입은 Father 타입과 Mother 타입의 모든 속성을 가지는 타입이 됨
• 그러나 새롭게 선언한 me 객체가 Father와 Mother의 attribute 모두를 가지고 있지 않아서 오류 발생
  (beauty, smart, brave, healthy 속성을 모두 가져야 오류가 발생하지 않음)

✏️ 구조체 파생하기

// 타입 선언
type Me = Pick<Father & Mother, AttrType.BRAVE | AttrType.SMART>;

• Pick이라는 키워드 사용 (infer 관련 강의)
• 첫 번째 필드에는 원본이 되는 타입, 두 번째 필드에는 가져올 attribute를 넣어줌 (or로 구분)

 

🧩 인터페이스

JS에는 인터페이스가 없음

• 타입 참조도 참조! 참조는 곧 의존성
• JS에서는 인터페이스 없이 의존성 역전이 가능, TS에서는 인터페이스 필요

 

 

// controller.ts
import { EventBus } from './eventBus';
import { View } from './view';

export class Controller {
  constructor(view: View, eventBus: EventBus) {
    eventBus.on();
    view.render();
  }
}

// view.ts
import { EventBus } from './eventBus';

export class View {
  constructor(eventBus: EventBus) {
    eventBus.trigger();
  }

  public render() {}
}

• JS 의존성 주입이 있는 아키텍처 코드를 TS로 변환하면 오류 발생함
• 오류를 해결하기 위해 View와 EventBus를 불러옴
  • 타입 참조도 의존성
  • 어떤 클래스가 존재한다는 것을 아는 것의 의존성
  • 의존성 역전 법칙에 의하면 의존관계를 발전시켜야 상위 계층이 하위 계층의 구현으로부터 독립될 수 있음
  • TS에서 의존성 역전을 하기 위해서는 인터페이스가 필요함

 

// controller.ts
import { EventBus } from './eventBus';

export interface View {
  render(): void;
}
export class Controller {
  constructor(view: View, eventBus: EventBus) {
    eventBus.on();
    view.render();
  }
}

• 인터페이스를 선언하게 될 경우 controller는 더 이상 view 파일에 대한 의존성을 가지지 않고 view 인터페이스에 대한 의존성을 가짐

 

// view.ts
import { EventBus } from './eventBus';
import { View } from './controller';

export class ViewImpl implements View{
  constructor(eventBus: EventBus) {
    eventBus.trigger();
  }

  public render() {}
}

// main.ts
import { ViewImpl } from "./view";
...
class Main {
	...
	private view = new ViewImpl(this.eventBus);
	...
}

• controller에서 구현한 view 인터페이스를 구현하게 함
• controller 하위계층인 view를 참조하지 않고 상위계층인 controller를 참조하는 의존성 역전이 일어남

 

JS에는 메서드 오버로딩이 없음

메서드 오버로딩?

• TS에서는 할 수 있을 것 같지만 할 수 없음
• 인터페이스는 제공하지만, JS의 가변 인자로 구성해야 함

의존성이라는 개념이 있기 때문에 인터페이스를 이용해 의존성 주입받는 각각의 클래스에서 하나의 객체를 다른 방식으로 사용하게 할 수 있음

// controller.ts
// import { EventBus } from './eventBus'; 삭제

interface EventHandler {
  on(): void;
}

export class Controller {
  constructor(view: View, eventBus: EventHandler) {
    eventBus.on();
    view.render();
  }
}

• EventBus를 바로 받아서 사용하는 대신 EventHandler 인터페이스 구현

 

// view.ts
interface EventTrigger {
    trigger(): void;
}

export class ViewImpl implements View{
  constructor(eventBus: EventTrigger) {
    eventBus.trigger();
  }

  public render() {}
}

• EventTrigger 인터페이스 구현

 

// eventBus.ts
import { EventHandler } from './controller';
import { EventTrigger } from './view';

export class EventBus implements EventHandler, EventTrigger {
  on(){};
  trigger(){};
}

• EventHandler와 EventTrigger 두 개의 인터페이스 상속
• view와 controller는 동일한 eventBus라는 객체를 의존성 주입 받고 있음
• 그런데 controller에서는 eventHandler의존, view에서는 eventTrigger 의존하고 있기 때문에 controller에서는 on 메서드, view에서는 trigger 메서드만을 사용할 수 있음 → 단방향 eventBus 구현

 

🛴 타입 캐스팅

타입 캐스팅?

다운 캐스팅?

 

타입 캐스팅을 할 때는 변수나 타입을 미리 선언하자

• 타입 캐스팅(as)을 할 때는 괄호로 감싸지 말고 변수를 선언하자
• 제네릭을 사용할 때마다 인자를 입력하지 말고, 미리 제네릭이 포함된 타입을 선언하자

 

무엇이 TS를 TS답게 하는가

• 무조건 코드를 짧게 쓰는 것도, 무조건 타입을 추가하는 것도 능사가 아니다.
• 최대한으로 코드의 변경을 축적하고, IDE의 도움을 얻기 위해 노력하자.
• 타입을 선언하고, 사용할 때에는 이것이 코드 추적에 어떤 도움을 줄까 생각해보자. 여기 들어간 노력은 더 큰 이득으로 돌아올 것이다.