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とPropTypesは目的が異なります。Typescriptはコンパイル時に型を検証しますが、PropTypeは実行時にチェックされます。

Typescriptは、コードを記述するときに便利です。間違った型の引数をReactコンポーネントに渡すと警告が表示され、関数呼び出しのオートコンプリートが提供されます。

APIからJSONをロードする場合など、コンポーネントが外部データとどのように相互作用するかをテストする場合、PropTypeは役立ちます。PropTypesは、コンポーネントが失敗している理由（Reactの開発モードの場合）をデバッグするのに役立ちます。

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

TypescriptとPropTypesは同じように見えるかもしれませんが、実際にはまったく重複していません。ただし、TypescriptからPropTypeを自動的に生成することができるので、タイプを2回指定する必要がありません。たとえば、

• 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、実行時に使用することで生成された警告を確認すると役立つと思います。

そのような状況の1つは、制御が及ばない外部APIなど、タイプ定義が利用できない外部ソースからのデータを処理する場合です。内部APIについては、型定義がまだ利用可能でない場合は、それを記述（または、より適切には、生成）する価値があると思います。

それ以外は、特にメリットはありません（個人的に使用したことがないのはそのためです）。