✨ TypeScript의 광고 아이디어-JS 튜토리얼-php.cn

저는 TypeScript를 사랑합니다.

특히 JavaScript의 악명 높은 "정의되지 않은 값에 액세스할 수 없습니다" 오류를 경험한 후

그러나 TypeScript가 훌륭하더라도 여전히 발을 쏴버릴 수 있는 방법이 있습니다.

이번 게시물에서는 TypeScript의 5가지 나쁜 습관과 이를 방지하는 방법을 공유하겠습니다.

? 빠른 시작을 위해 무료 101가지 React 팁 및 요령 책을 다운로드하세요.

✨ ad Ideas in TypeScript

1. 오류를 Any 유형으로 선언하기

예

다음 코드 조각에서는 오류를 포착한 후 이를 any 유형으로 선언합니다.

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err: any) {
    toast(`Failed to do something: ${err.message}`);
  }
}

로그인 후 복사

왜 나쁜가요 ❌

오류에 문자열 유형의 메시지 필드가 있다는 보장은 없습니다.

안타깝게도 유형 주장 때문에 코드에서는 그렇다고 가정할 수 있습니다.

코드는 특정 테스트 사례를 사용하여 개발 중에는 작동할 수 있지만 프로덕션에서는 심각하게 중단될 수 있습니다.

대신해야 할 일 ✅

오류 유형을 설정하지 마세요. 기본적으로 알려지지 않아야 합니다.

대신 다음 중 하나를 수행할 수 있습니다.

옵션 1: 유형 가드를 사용하여 오류 유형이 올바른지 확인하세요.

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err) {
    const toastMessage = hasMessage(err)
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;
    toast(toastMessage);
  }
}

// We use a type guard to check first
function hasMessage(value: unknown): value is { message: string } {
  return (
    value != null &&
    typeof value === "object" &&
    "message" in value &&
    typeof value.message === "string"
  );
}

// You can also simply check if the error is an instance of Error
const toastMessage = err instanceof Error
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;

로그인 후 복사

옵션 2(권장): 오류에 대해 가정하지 마세요

오류 유형에 대해 가정하는 대신 각 유형을 명시적으로 처리하고 사용자에게 적절한 피드백을 제공하세요.

구체적인 오류 유형을 알 수 없는 경우 부분적인 세부 정보보다는 전체 오류 정보를 표시하는 것이 좋습니다

오류 처리에 대한 자세한 내용은 훌륭한 오류 메시지 작성 가이드를 참조하세요.

✨ ad Ideas in TypeScript

2. 동일한 유형의 여러 연속 매개변수를 갖는 함수 보유

예

export function greet(
  firstName: string,
  lastName: string,
  city: string,
  email: string
) {
  // Do something...
}

로그인 후 복사

왜 나쁜가요 ❌

실수로 매개변수를 잘못된 순서로 전달할 수 있습니다.

// We inverted firstName and lastName, but TypeScript won't catch this
greet("Curry", "Stephen", "LA", "stephen.curry@gmail.com")

로그인 후 복사

특히 코드 검토 중에 선언 전에 함수 호출을 보면 각 매개변수가 무엇을 나타내는지 이해하기가 더 어렵습니다

대신 무엇을 해야 할까요 ✅

객체 매개변수를 사용하여 각 필드의 목적을 명확히 하고 실수 위험을 최소화하세요.

export function greet(params: {
  firstName: string;
  lastName: string;
  city: string;
  email: string;
}) {
  // Do something...
}

로그인 후 복사

✨ ad Ideas in TypeScript

3. 다중 분기 및 반환 유형이 없는 함수 보유

예

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err: any) {
    toast(`Failed to do something: ${err.message}`);
  }
}

로그인 후 복사

왜 나쁜가요 ❌

새 동물 유형을 추가하면 잘못 구조화된 객체가 반환될 수 있습니다.
반환 유형 구조를 변경하면 코드의 다른 부분에서 추적하기 어려운 문제가 발생할 수 있습니다.
오타로 인해 잘못된 유형이 유추될 수 있습니다.

대신 무엇을 해야 할까요 ✅

함수의 반환 유형을 명시적으로 지정합니다:

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err) {
    const toastMessage = hasMessage(err)
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;
    toast(toastMessage);
  }
}

// We use a type guard to check first
function hasMessage(value: unknown): value is { message: string } {
  return (
    value != null &&
    typeof value === "object" &&
    "message" in value &&
    typeof value.message === "string"
  );
}

// You can also simply check if the error is an instance of Error
const toastMessage = err instanceof Error
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;

로그인 후 복사

✨ ad Ideas in TypeScript

4. 선택적 필드를 사용하는 대신 불필요한 유형 추가

예

export function greet(
  firstName: string,
  lastName: string,
  city: string,
  email: string
) {
  // Do something...
}

로그인 후 복사

왜 나쁜가요 ❌

확장되지 않음: 새 필드를 추가하려면 여러 개의 새로운 유형을 만들어야 합니다
유형 검사가 더욱 복잡해져 추가 유형 가드가 필요합니다
유형 이름이 혼란스럽고 유지 관리가 더 어려워집니다

대신 무엇을 해야 할까요 ✅

유형을 단순하고 유지 관리하기 쉽게 유지하려면 선택 필드를 사용하세요.

// We inverted firstName and lastName, but TypeScript won't catch this
greet("Curry", "Stephen", "LA", "stephen.curry@gmail.com")

로그인 후 복사

✨ ad Ideas in TypeScript

5. 다양한 구성 요소 수준에서 속성을 선택 사항으로 만들기

예

비활성화된 소품은 모든 구성 요소에서 선택 사항입니다.

export function greet(params: {
  firstName: string;
  lastName: string;
  city: string;
  email: string;
}) {
  // Do something...
}

로그인 후 복사

왜 나쁜가요 ❌

비활성화된 prop을 전달하는 것을 잊어버리기 쉽고 부분적으로 활성화된 양식이 발생함

대신 무엇을 해야 할까요 ✅

내부 구성요소에 대한 공유 필드를 필수로 만드세요.

이렇게 하면 Prop이 제대로 전달될 수 있습니다. 이는 하위 수준 구성 요소가 감독을 조기에 포착하는 데 특히 중요합니다.

위의 예에서는 이제 모든 내부 구성 요소에 비활성화가 필수입니다.

function getAnimalDetails(animalType: "dog" | "cat" | "cow") {
  switch (animalType) {
    case "dog":
      return { name: "Dog", sound: "Woof" };
    case "cat":
      return { name: "Cat", sound: "Meow" };
    case "cow":
      return { name: "Cow", sound: "Moo" };
    default:
      // This ensures TypeScript catches unhandled cases
      ((_: never) => {})(animalType);
  }
}

로그인 후 복사