Destructuring 및 인라인 유형이 TypeScript 코드베이스를 손상시키는 5가지 이유

최근에 Jamie Kyle이 디스트럭처링, 기본 매개변수, 인라인 유형을 사용하는 것에 대한 트윗을 보았습니다.









제이미 카일 🏳️‍🌈


@buildsghost






논란의 여지가 있을 수 있지만 이것이 내가 구조 분해, 기본 매개변수, 인라인 유형 등을 사용하지 않는 이유입니다. All this or:enqueueMessageForSend( message: MessageDetails, options: MessageOptions,): Promise {...}


오후 20:18 - 2022년 10월 3일











최근 직장에서 본 트윗과 몇 가지 React 구성 요소가 이 블로그 게시물을 작성하도록 영감을 주었습니다. Destructuring 및 인라인 유형을 사용하여 TypeScript의 가독성을 떨어뜨리는 방법을 보여드리고 싶습니다!

TypeScript 함수 정의는 어떻게 생겼습니까?



JavaScript 및 TypeScript에서 function 키워드 또는 람다/화살표 함수를 사용하여 함수를 정의할 수 있습니다. 두 방법 모두 유효하지만 차이점이 있습니다. 간단한 sendMessage 함수를 살펴보겠습니다. 구현 논리는 우리와 관련이 없습니다.

// sendMessage function written using `function` keyword
function sendMessage(message: string) {
  // function logic
}

// same sendMessage written as arrow function
const sendMessage = (message: string) => {
  // function logic
};


함수 정의가 매우 간단할 때 함수는 다른 유형의 몇 가지 매개변수를 허용합니다. 문자열이나 숫자와 같은 프리미티브라면 모든 것을 읽을 수 있습니다.

메시지 콘텐츠와 함께 몇 가지 추가 정보를 sendMessage 함수에 전달하려고 한다고 가정해 보겠습니다.

function sendMessage(message: {
  content: string;
  senderId: string;
  replyTo?: string;
}) {
  // you can assess content using `message.content` here
}


보시다시피 TypeScript를 사용하면 message 또는 type 키워드를 사용하여 유형을 지정하지 않고 전달하려는 interface 객체에 대한 인라인 유형 정의를 작성할 수 있습니다.

디스트럭처링을 추가해봅시다. 큰message 객체를 함수에 전달할 때 TypeScript는 전달된 인수를 분리하여 message 변수를 여러 번 반복하는 코드 상용구를 줄일 수 있습니다.

function sendMessage({
  content,
  senderId,
  replyTo,
}: {
  content: string;
  senderId: string;
  replyTo?: string;
}) {
  // you have access to `content` directly
}


나쁜 아이디어라고 생각하는 이유와 이를 개선할 수 있는 방법



좋은 아이디어처럼 보일 수도 있지만 결국 message를 그렇게 많이 쓸 필요는 없겠죠? 그다지 좋지 않다는 것이 밝혀졌습니다. 반패턴이라고 생각하는 5가지 이유에 대해 이야기해 봅시다.

1. 데이터의 출처가 확실하지 않습니다.



함수 본문을 읽을 때 senderId가 표시되면 해당 함수가 어디에서 왔는지 다시 확인해야 합니다. 인수로 전달되거나 함수 어딘가에서 계산됩니까?

2. 문서 작성이 어렵다



함수 정의에서 모든 유형이 비구조화로 꽉 차 있을 때 문서 주석을 작성할 자연스러운 장소가 없습니다. 각 유형 필드 사이에 주석을 작성할 수 있지만 전체 함수 정의가 더 길어집니다. 전달하는 데이터에 대한 빠른 요약을 작성하는 것을 적극적으로 권장하지 않습니다.

3. 해당 데이터를 전달하기가 어렵습니다.



데이터가 구조화되면 전달하려면 데이터를 새 개체로 다시 구조화해야 합니다. 이는 더 작은 도우미 함수를 만들고 구성에 의존하여 기본 함수 논리를 구축하는 것을 권장하지 않습니다.

4. 이 함수 외부에서 인수 유형을 재사용할 수 없습니다.



기본 함수 논리를 구성할 때 도우미 함수에서 함수 인수를 재사용해야 하는 경우 동일한 형식 집합을 반복적으로 입력해야 합니다. 이렇게 하면 유형을 전혀 작성하지 않는 것이 더 쉬워집니다.

5. 공간을 많이 차지합니다.



현실을 직시하자. 많은 화면 공간을 차지하는 코드 줄입니다. 또한 구현 세부 사항, 즉 함수에 전달하는 인수의 내부 유형에 중점을 둡니다. 이는 해당 함수를 볼 때 대부분 관련이 없습니다.

그냥 유형을 만드십시오



유형을 추출하여 함수 바로 위에 배치하면 훨씬 더 읽기 쉽습니다. 문서 주석을 위한 장소가 있습니다. 다른 도우미 함수에서 해당 유형을 재사용하고 필요한 경우 한 곳에서 유형 정의를 변경할 수 있습니다.

/**
 * Message to send using XYZ API
 */
export type MessageToSend = {
  /**
   * Markdown string of the user's message
   */
  content: string;
  /**
   * Id of the sender user
   */
  senderId: string;
  /**
   * Other message ID if this is a reply
   */
  replyTo?: string;
};

function sendMessage(message: MessageToSend) {
  // function logic
}

function getUserIdsToNotify(message: MessaageToSend) {
  // function logic
}


자원



이 블로그 게시물을 조사할 때 사용한 리소스 목록:

https://www.typescriptlang.org/docs/handbook/variable-declarations.html#object-destructuring

좋은 웹페이지 즐겨찾기