コンポーネントのプロパティを説明するには、常にPropタイプを使用します。
Prop- types-ランタイムモードでReactプロパティと同様のオブジェクトのタイプをチェックするためのモジュール。 prop-typesは、コンポーネントに渡されたプロパティを目的のタイプと照合します。
コンポーネントに渡されたプロパティのタイプが説明と一致しない場合、ブラウザコンソールに警告が表示されます。 上記の例では、コンソールに次の警告が表示されます。
"Warning: Failed prop type: Invalid prop `message` of type `string` supplied to `Hello`, expected `array` in Hello"
このメッセージから、文字列型のメッセージプロパティがHelloコンポーネントに渡されますが、配列が想定されます。
コンポーネントごとにpropTypeを記述するのが嫌な場合は、TypeScriptを使用することができます。これにより、デバッグ中ではなく、プロジェクトのコンパイル時にコンポーネントの互換性を確認できます。 統合フロントエンドシステムの開発では、フィードバック速度により大規模プロジェクトの開発コストが大幅に削減されるため、TypeScriptを使用します。
displayNameを使用してコンポーネント名を決定します
displayName文字列は、デバッグメッセージで使用されます。 コンポーネントでdisplayNameをまだ使用していない場合は、必ず試してみてください！
通常、 React開発者ツール拡張機能を使用してコードをデバッグする場合、コンポーネントを説明する関数またはクラスの名前から名前が取られたコンポーネントが表示されます。 ただし、同じ名前（ボタン、ドロップダウンなど）の2つのコンポーネントがある場合、ほとんどの場合、そのうちの1つを名前変更する必要があります。 そうしないと、それらを区別できません。
displayNameはこの問題を解決します-このプロパティを設定することでコンポーネントの名前を変更できます。 上記の例では、クラスの名前はComponentですが、DisplayNameがHelloであるため、React開発者ツール拡張にHelloという名前が表示されます。
この手法はデバッグには非常に便利ですが、多くの場合、過小評価されています。
また、製品アセンブリでは、すべてのコンポーネント名が難読化されているため、React DevToolsにコンポーネントの名前が表示されない場合があります。 displayNameを使用すると、コンポーネントの名前を表示でき、バトル設定でもエラーを見つけやすくなります。
リンターを使用してコードのチェックを簡単にします
コードのクリーンさを重視する場合は、リンターを使用してテストする必要があります。 このようなツールは、チームのコードスタイルを統一するのに役立ちます。指定されたルールを厳密に守れば、コードベースは常に均一になります。
たとえば、行末にセミコロンを使用するルールにすることができます。 開発者がこの規則に従わない場合、設定に応じてlinterはエラーメッセージまたは警告を表示します。
最も有名なリンターはESLintですが、他の適切なツールを使用できます。
ESFプラットフォームのプロジェクトはTypeScriptで開発されているため、作業ではTSLintを使用します。このチェックは各プルリクエストで起動されますが、コマンドで受け入れられるコードスタイルに対応しないメインブランチコードにマージすることはできません。
最初の反復が常に最良とは限りません
あなたの多くはこれを知っています-最初の反復が常に最良であるとは限りません。 ソースコードを慎重に確認し、不足している可能性のあるものについて考える必要があります。 これを検証する1つの方法は、優れているがめったに使用されないテスト駆動開発（TDD）テクニックを使用することです。 このアプローチを使用すると、最初の反復が最適な場合があります。 コードの最初の行を書く前に、そして新しい機能を導入するかバグを修正する前に、何をしようとしているのかを考えてください。加えられた変更を見て、それらを改善する方法を考えてください。
統合フロンタルシステムプログラムには、いくつかのタイプのテストがあります。カルマ+ジャスミンスタックで構築された単体テストに加えて、ジェミニテクノロジーで構築されたスクリーンショットの比較による回帰テストを使用します。 大規模なアプリケーションを開発する際、統合テストに多くの注意を払っています。 関連するケースや例を持っている人を詳細に開示するつもりはありません。コメントで議論しましょう。
プロジェクトの構造は明確でなければなりません。
大きな関数を小さな関数に分割すると、これらの関数を再利用できます。 さらに、小さな機能はテストが簡単です。 コードの重複をなくすために、コードの繰り返し部分を特別なサービスファイルに配置できます。
コードを使用して複数のファイルを作成した後、見れば、おそらく互いに重複する行があります。 サービスファイルに配置して、他のファイルで使用できます。
さらに、1つのファイルを多数の小さなファイルに分割することが重要です。 1つの大きなファイルの分析は、いくつかの小さなファイルよりも常に困難です。 コードをいくつかの小さなファイルに分割すると、それぞれに独自のロジックが含まれ、これらのファイルを表示するのが簡単になります。
ファイルを呼び出すときは十分注意してください。
覚えておくべきもう1つのポイントは、ファイルに含まれる機能に応じてファイルに名前を付けると、このファイルで実際に何が起こっているかを理解するのに役立ちます。
たとえば、dropdown.jsは良い名前ですが、あまりにも一般的であるため、同じディレクトリ内の複数のファイル（topDropdown.js、bottomDropdown.jsなど）に使用することは悪い習慣です。
ファイル名のプレフィックスとして、ファイル内のコードが実行する必要があるタスクを使用することをお勧めします。 たとえば、userDropdown.js、fileDropdown.jsなど。
コードのテストを常に書く
このアドバイスの重要性を過大評価することはできません。 新しい機能を開発した後、コードが機能することを望みます-実際に機能します。 しかし、ほとんどの場合、境界条件が発生すると、正しく動作しなくなります。 テストは、そのようなケースを識別するのに役立ちます。
テストを書くと開発時間が長くなることは明らかですが、同時に可能性のあるエラーを排除し、将来の検索と修正の時間を節約するのに役立ちます。
アプリケーションの品質に関心がある場合は、時間をかけてテストを作成してください。
エラー処理技術を乱用しないでください
React 16は、 エラーを処理する効果的な方法-エラー境界を導入しました。
本質的に、エラー境界は、子コンポーネントのエラーをキャッチし、破損したコンポーネントの代わりにフォールバックUIを表示するReactコンポーネントです。
ErrorBoundaryコンポーネントにフォールバックコードが存在する場合、YourComponentコンポーネントをその中にカプセル化できます。
<ErrorBoundary> <YourComponent/> </ErrorBoundary>
これは、エラーが発生した場合にコンポーネントのバックアップコードを出力する優れた方法です。 ただし、すべてのコンポーネントをErrorBoundary内に配置する必要はありません。 ErrorBoundaryコンポーネントは、コード内のいくつかの重要な場所にのみ配置できます 。
ESFプラットフォームの開発では、集中化されたエラー処理のためにエラー境界を使用します。 各エラーは特別なRESTサービスに分類され、アプリケーション開発中に発生したエラーを分析できます。
プルリクエストを送信する前にコードを確認してください
新しい機能を開発している場合でも、バグを修正している場合でも、変更を送信してプルリクエストを作成すると、急いでいる可能性が高くなります。
多くの場合、開発者は行われた変更を表示しません。つまり、大きな機能を小さな機能に分割し、コードをモジュールに分割することが合理的である場合、改善の機会はありません。 独自のコードを分析する習慣は、その品質の向上に役立ちます。
これは、コードレビューに影響を与える最も一般的な間違いの1つであるため、このヒントを明確にまとめました。 プルリクエストを開いた開発者は、まずすべての変更の概要を確認し、プルリクエストを開く直前にコードをチェックする代わりに、ブランチに新しいコミットを追加します。
説明したヒントがコードの改善に役立つことを願っています！ コメントでのディスカッションにご招待します。