web-dev-qa-db-ja.com

TypeScript ReactアプリケーションのPropTypes

TypeScript ReactアプリケーションでReact.PropTypesを使用することは理にかなっていますか、これは単なる「ベルトとサスペンダー」の場合ですか?

コンポーネントクラスはProps型パラメーターで宣言されているため:

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

追加することに本当の利点はありますか

static propTypes {
    myProp: React.PropTypes.string
}

クラス定義に?

56
Ralph

通常、コンポーネントの小道具をTypeScript型とReact.PropTypesの両方で同時に維持することはあまり価値がありません。

以下は、そうすることが有用ないくつかのケースです。

  • プレーンJavaScriptで使用されるコンポーネントライブラリなどのパッケージを公開します。
  • API呼び出しの結果などの外部入力を受け入れて渡す。
  • 適切または正確なタイピングがない場合、ライブラリのデータを使用します。

したがって、通常は、コンパイル時の検証をどれだけ信頼できるかという問題です。

TypeScriptの新しいバージョンでは、React.PropTypesPropTypes.InferProps)に基づいて型を推測できるようになりましたが、結果の型を使用したり、コードの他の場所で参照したりするのは困難です。

57
Joel Day

TypeScriptとPropTypesは異なる目的を果たします。 TypeScriptはcompile timeで型を検証しますが、PropTypesはruntimeでチェックされます。

TypeScriptは、コードを記述しているときに便利です。Reactコンポーネントに間違った型の引数を渡すと、関数呼び出しのオートコンプリートなどを警告します。

PropTypesは、コンポーネントが外部データとどのようにやり取りするかをテストする場合、たとえばAPIからJSONをロードする場合に役立ちます。 PropTypesは、次のような有用なメッセージを出力することにより、コンポーネントが失敗する理由をデバッグするのに役立ちます(Reactの開発モードの場合)

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

TypeScriptとPropTypesは同じことをしているように見えるかもしれませんが、実際にはまったく重複していません。ただし、TypeScriptからPropTypesを自動的に生成することが可能であるため、型を2回指定する必要はありません。例:

28
afonsoduarte

コンパイル時に小道具のタイプを推測できない厄介な状況では、propTypesを使用して生成された警告を確認すると役立つと思います。

それ以外に、私は実際には何の利点も見ていません(個人的に使用したことがないのはこのためです)。

4
Tom Fenech