しないでください:mapStateToProps から新しい配列または新しいオブジェクトを返します。オブジェクトを返す場合は、後で変更されないように注意してください。これにより、このオブジェクトが少しでも変更されると、コンポーネントとサブツリー全体が再レンダリングされる可能性があります。 

Do:mapstateToProps は、状態から直接取得されるプリミティブと配列のみを返す必要があります (mapStateToProps から新しい配列を作成しないでください。必要に応じて、引数の計算から得られた配列をキャッシュするセレクターを作成します)。後で反復処理される配列には、レンダリングされる項目の文字列 ID が含まれている必要があります。リスト項目は、props.

Do: 独自のカスタムフックを構築するときは、返される配列もメモ化されていることを確認してください。時期尚早の最適化は推奨されていませんが、できる限り最適な方法で何かを構築してみてはいかがでしょうか。多大な労力がかからず、コードに取り組む他のエンジニアの学習も促進されます。チームのスキルアップ!

Do: 大きなオブジェクトを構築する場合は、キーをアルファベット順に並べます。オブジェクトのサイズが大きくなる可能性があり、プロパティの検索に非常に時間がかかる場合があります。特にストアでは、リデューサーがアルファベット順に並べられていることを確認してください。

してはいけない: 構築しているページ/画面に固有のリデューサーを構築します。他のページや画面にどのように拡張できるかを考えてください。作成中のページ/画面の将来の使用可能性を確認するには、チームに相談してください。

Do: 外部 API との通信をカスタムメイドの API でラップするようにしてください。将来、サービスを置き換える必要がある場合は、このカスタムメイドの API で行うことができます。たとえばバグスナッグについて考えてみましょう。将来 Sentry を使いたい場合に備えて、その男の子をカスタムメイドの API でラップしてください。

Do: 同じ意見です。バックエンドだけでなくフロントエンドでもエラーを処理する方法を標準化してください。アプリ内のすべてのアクションは try/catch ブロックでラップする必要があり、catch ブロックはレポートをバグ報告ツールに送信します。アプリでは、アプリ全体をエラー境界でラップする必要もあります。適切なパターンを確立する適切な方法があると私は信じています。すべてのエラーを捕捉し、意味のある情報を報告できるパターン。

Do: Sonar などのコード品質を強制するツールを使用します。これにより、コード レビュー中に時間を大幅に節約できます。これは、誰かが if ... return の代わりに if ... else を使用することを決定したためです。 。小さな些細な詳細により、開発者は創造性が低下し、コード品質のソナー基準に従うだけになります。これらの詳細にまで徹底したコードベースは、初日から簡単にコーディングできます。

結論

現時点での意見は以上です。パターンを強制するコードベースがあれば、人々はコードベースの他の場所からコードの一部を取得して貼り付け、文言を少し変更するだけで、可能な限りすべての点で実稼働標準を満たす機能が完成します。意見はありますが、少なくともこの記事の執筆時点では、本当に最もパフォーマンスの高い方法があります。他のアプローチも将来的には考えられますが、コードを作成する時点で最もパフォーマンスの高い方法がコードを記述する唯一の方法です。締め切りというモンスターに遭遇するまでは、言うは易し行うは難し。