web-dev-qa-db-ja.com

コンポーネントの小道具タイプが無効な場合にアプリをビルドしないようにするにはどうすればよいですか？

PropTypesの例を次に示します。

import PropTypes from 'prop-types';

class Greeting extends React.Component {
  render() {
    return (
      <h1>Hello, {this.props.name}</h1>
    );
  }
}

Greeting.propTypes = {
  name: PropTypes.string
};

ここで、Greetingコンポーネントを次のように使用します。

<Greetings otherProp="this is a invalid prop" />

この場合、デプロイ用のアプリをビルドすると、エラーはスローされず、アプリは正常にビルドされます。しかし、それは実行時にエラーを出し、故障します。

この問題を取り除き、間違ったプロップタイプを使用してコンポーネントが構築されていないことを確認するには、チェックを追加するにはどうすればよいですか。

javascriptreactjsreact-proptypes
14
demonofthemist

あなたの質問は、PropTypesの意図と実装の両方の誤解から生じます。 PropTypesは、API使用の構成可能な実行時検証を提供するために存在します。静的コード分析は実行しませんが、実行時に使用状況を検証します。

追加のコンテキストを提供するために、この概念は、多くの静的分析ツールの主流の使用法よりも前のものです。さらに、これらのツールが導入されたとしても、実行時検証アプローチを好む人もいます。この理由の1つは、ツールチェーンの単純さを維持することである可能性があります。 PropTypes検証は、追加のツールや言語なしでVanillaJavaScriptで機能します。ただし、JSXを使用しているため、複数の言語を含む複雑なツールチェーンがすでに存在するため、この考慮事項はあまり重要ではありません。ただし、PropTypesを使用するもう1つの理由は、ライブラリを構築している場合でも、選択した静的分析ツールと同じ、またはさらに言えば、使用することなく、消費者に一定レベルの検証を提供できることです。 。

コードを実行する前にコードの正確さを検証する場合は、静的分析ツールを使用する必要があります。多くのオプションがあり、複数のツールを使用できますが、いくつかの例には、 TypeScript 、 Flow 、および Closure Compiler が含まれます。

これらの静的分析オプションはいずれも、定義上、PropTypesに直交しているため、自由に一緒に使用できることに注意してください。したがって、PropTypesの使用を中止することをお勧めするのではなく、ユースケースに対応する静的分析ツールを追加することをお勧めします。

14
Aluan Haddad

私の個人的な推奨事項は、 Aluan Haddad が述べたように、静的コード分析ツールを使用することです。

静的コード分析ツールを使用したくない場合は、 https://github.com/esphen/jest-prop-typeなどのツールを使用してテストでコードを失敗させることができます。 -エラー 。ただし、これは、異なるコンポーネント間の統合を完全にカバーするテストが必要であることを意味します。

私はこれを最終的な解決策とは見なしませんこの問題の場合ですが、静的コード分析ツールに移行する際の大規模なコードベースの一時的な解決策として役立つ可能性があります。

4
Martin Prins

Reactの背後にある考え方はコンポーネントベースです。 Prop-typesは、React propsおよび同様のオブジェクトのランタイム型チェックです。prop-typesを使用して、コンポーネントに渡されるプロパティの目的の型を文書化できます。

Greetingコンポーネントで、小道具としてnameが必要な場合は、小道具タイプで定義する必要があります。 nameが必要な場合は、次のように定義します。

Greeting.propTypes = {
  name: PropTypes.string.isRequired
};

Greetingを使用するには、それを呼び出して小道具を渡すだけです。 Greetingコンポーネントに渡したものを確認する必要はないと思います。

0
Vu Luu