하나의 간단한 원칙에 따라 Typescript에서 더 나은 유형을 디자인하는 방법

몇 년이 지나도 즐겁게 작업할 수 있는 유지 관리가 가능하고 수명이 긴 모든 React 코드베이스는 한 가지를 공유합니다.
그들은 올바른 구조를 가진 데이터를 중심으로 구축된 구성 요소로 구성됩니다.
React에 대한 내가 가장 좋아하는 텍스트 중 하나는 이것을 완벽하게 설명합니다.
Defining Component APIs in React

그러나 공식 React 문서조차도 애플리케이션 데이터에 적합한 구조를 선택하고 해당 데이터를 중심으로 구성 요소를 구축하는 것의 중요성을 강조합니다.

Since you’re often displaying a JSON data model to a user, >you’ll find that if your model was built correctly, your UI >(and therefore your component structure) will map nicely.
Thinking in React

다행히도 애플리케이션 데이터를 매우 쉽게 모델링할 수 있는 간단한 원칙이 있습니다.

이 기사는 가장 중요한 것으로 시작합니다.
우리 모델이 다루는 공간에는 우리 도메인에서 유효한 사례만 포함되어야 합니다.

간단한 예: 자동차 만들기

다음 예제는 평균적인 Typescript 코드베이스에 대해 그다지 현실적이지 않을 수 있지만, 그 유형은 모든 코드베이스의 일부인 두 가지 기본 구조의 예제입니다.

먼저 자동차 구성 모델링 시도

자동차를 만들기 위해 다음과 같은 유형을 생각해낼 수 있습니다.

type PowerSource = "gas tank" | "battery"
type Engine = "electric motor" | "petrol engine" | "diesel engine"
type Fuel = "petrol" | "diesel" | "electrons"

type Car = {
  engine: Engine
  fuel: Fuel
  powerSource: PowerSource
}

자동차 유형을 살펴보겠습니다. 세 종류의 엔진, 세 종류의 연료 및 두 가지 다른 유형의 동력원이 있습니다.
제품 복용
2x3x3
가능한 모든 자동차 구성의 수는 18입니다. 처음에는 모든 것이 멋지고 멋져 보입니다. Typescript가 자동차 부품에 임의의 문자열을 할당하는 것을 방지하고 오타를 성공적으로 방지하게 되어 기쁩니다.

다음 예는 유효한 자동차를 보여줍니다.

const buggyCar: Car = {
  engine: "petrol engine",
  fuel: "diesel",
  powerSource: "gas tank",
}

그러나 탱크를 채우고 엔진을 시동하면 불쾌한 놀라움이 생깁니다.
디젤로 가솔린 엔진에 동력을 공급하는 것은 확실한 죽음이 될 것입니다. 그러나 조합은 유효한 유형입니다.
이와 같은 실패를 즉시 방지하기 위해 유형을 어떻게 설계할 수 있습니까?

우리 차를 위한 더 나은 유형 디자인하기

도메인을 분석하는 것으로 시작하고 바로 기능적인 자동차를 만들 수 있는 구성이 세 가지뿐임을 알 수 있습니다.

type ElectricCar = {
  engine: "electric motor"
  fuel: "electrons"
  powerSource: "battery"
}
type DieselCar = {
  engine: "diesel motor"
  fuel: "diesel"
  powerSource: "gas tank"
}

type PetrolCar = {
  engine: "petrol motor"
  fuel: "petrol"
  powerSource: "gas tank"
}

이제 자동차 유형을 이러한 인터페이스의 하나의 조합으로 모델링할 수 있습니다.

type Car = PetrolCar | ElectricCar | DieselCar

새 유형에는 이전 유형의 곱 2x3x3=18 대신 1+1+1=3 합계를 작성하여 케이스 수를 구하기 때문에 3개의 기능 자동차만 포함됩니다.
이전 유형을 사용했다면 자동차 구성의 오작동을 방지하기 위해 테스트와 문서화의 조합을 사용해야 합니다.

귀찮게 왜?

Typescript가 도움이 됩니다. 첫 번째 유형이라도 오타와 같은 작은 실수를 잡아서 버그를 방지했을 것입니다. 그러나 코드를 입력하면 의도나 지식을 다른 개발자에게 전달할 수도 있습니다. Elm, Clojure 또는 Haskell과 같은 다른 언어의 커뮤니티에 더 가까이 다가갈 수 있습니다. 우리는 많은 이익을 얻을 수 있습니다.

무엇 향후 계획?

다음 링크는 더 깊이 파고들기 위한 좋은 출발점입니다.

- WHAT DO PRODUCT AND SUM TYPES HAVE TO DO WITH DATA MODELING?

- "Making Impossible States Impossible" by Richard Feldman

어떻게 생각해?

Typescript로 인해 코드에 대한 생각이 바뀌었는지 말씀해 주시겠습니까? 유형을 제거해도 Typescript 코드가 JavaScript 코드와 여전히 다르게 보입니까?
Typescript를 통해 다른 커뮤니티에서 더 가까이 배울 수 있다고 생각하십니까?