TypeScript React 애플리케이션의 PropTypes

React.PropTypesTypeScript React 애플리케이션에서 사용하는 것이 합리적 입니까, 아니면 "벨트 및 멜빵"의 경우입니까?

컴포넌트 클래스는 Props유형 매개 변수로 선언되므로 :

interface Props {
    // ...
}
export class MyComponent extends React.Component<Props, any> { ... }

추가하는 것이 실질적인 이점이 있습니까?

static propTypes {
    myProp: React.PropTypes.string
}

클래스 정의에?

일반적으로 구성 요소 소품을 TypeScript 유형으로 동시에 유지하는 데는 그다지 가치가 없습니다 React.PropTypes.

이렇게하는 것이 유용한 경우는 다음과 같습니다.

• 일반 JavaScript에서 사용할 구성 요소 라이브러리와 같은 패키지를 게시합니다.
• API 호출의 결과와 같은 외부 입력을 수락하고 전달합니다.
• 적절하거나 정확한 입력이없는 라이브러리의 데이터를 사용하는 경우.

따라서 일반적으로 컴파일 시간 유효성 검사를 얼마나 신뢰할 수 있는지에 대한 질문입니다.

최신 버전의 TypeScript는 이제 React.PropTypes( PropTypes.InferProps)를 기반으로 유형을 추론 할 수 있지만 결과 유형은 코드의 다른 곳에서 사용하거나 참조하기 어려울 수 있습니다.

Typescript와 PropType은 다른 용도로 사용됩니다. Typescript는 컴파일 시간에 유형의 유효성을 검사 하는 반면 PropType은 런타임에 확인 됩니다 .

Typescript는 코드를 작성할 때 유용합니다. 잘못된 유형의 인수를 React 구성 요소에 전달하면 경고하고 함수 호출에 대한 자동 완성 기능을 제공합니다.

PropTypes는 구성 요소가 외부 데이터와 상호 작용하는 방식을 테스트 할 때 유용합니다 (예 : API에서 JSON을로드 할 때). PropTypes는 다음과 같은 유용한 메시지를 인쇄하여 구성 요소가 실패한 이유를 디버깅하는 데 도움이됩니다 (React의 개발 모드 일 때).

Warning: Failed prop type: Invalid prop `id` of type `number` supplied to `Table`, expected `string`

Typescript와 PropType이 동일한 작업을 수행하는 것처럼 보이지만 실제로는 전혀 겹치지 않습니다. 그러나 Typescript에서 자동으로 PropType을 생성 할 수 있으므로 유형을 두 번 지정할 필요가 없습니다. 예를 들면 다음과 같습니다.

• https://github.com/milesj/babel-plugin-typescript-to-proptypes
• https://github.com/grncdr/ts-react-loader#what-it-does
• https://github.com/gcanti/prop-types-ts

컴파일 타임에 소품의 유형을 추론 할 수없는 지저분한 상황에서는 propTypes런타임에 사용하여 생성 된 경고를 보는 것이 유용 할 것 같습니다 .

이러한 상황 중 하나는 사용자가 제어 할 수없는 외부 API와 같이 유형 정의를 사용할 수없는 외부 소스의 데이터를 처리하는 경우입니다. 내부 API의 경우 아직 사용할 수없는 경우 유형 정의를 작성 (또는 더 잘 생성)하려는 노력의 가치가 있다고 생각합니다.

그 외에는 실제로 어떤 이점도 보지 못합니다 (개인적으로 사용하지 않은 이유입니다).