いつ、どのようにReactフックと古いHOC小道具を渡すか？
これまでは、小道具を介してコンポーネントにデータが入力されるフラックスフローに慣れていました。したがって、Propsシグネチャを見て、コンポーネントの要件を確認できます。
フックは素晴らしい機能ですが、それらに移行すると、実際のコンポーネントコードを見て確認する必要があるため、管理が難しい依存関係の別の入り口が提供されることがわかります。
もちろん、フックはコンテナコンポーネントでのみ使用できますが、その主なセールスポイントのいくつかは、ネストとHOCを削減する能力であると感じています。
どのコンポーネントがフックを使用し、どのコンポーネントがレンダープロップを使用するかを決定するための（現在）ベストプラクティスは何ですか？
React FAQs hooksによると、renderPropsとHOCsの代替として使用できますが、それらと共存できます
多くの場合、レンダープロップと高次コンポーネントは1つの子のみをレンダーします。フックは、このユースケースを提供するためのより簡単な方法だと思います。 まだ両方のパターンの場所があります（たとえば、仮想スクローラーコンポーネントにはrenderItemプロパティがあり、ビジュアルコンテナコンポーネントには独自のDOM構造があります）。ただし、ほとんどの場合、フックで十分であり、ツリーのネストを減らすのに役立ちます。
フックは、機能コンポーネントでステートフルロジックを許可し、Reactのクラスコンポーネントに似ています。
フックは、実際のコンポーネントコードを見て確認する必要があるため、管理が困難です。
そうではありません。HOCまたはrenderPropsにあるカスタムロジックをカスタムフックで引き出して、実際のコンポーネントで実際に何が行われているのかを理解する代わりに、その実装を探すことができるからです。
フックとHOCは異なるプログラミングモデルであり、それらを比較することはオレンジとリンゴを比較するように思われます。
TL; DR
経験則として、コンポーネントの条件付きレンダリングが必要な場合はHOCを使用し（条件の場合：Aをレンダリング、そうでない場合はBをレンダリング）、そうでない場合はフックを使用します。それは私の意見です。
長所短所：
HOCの長所
- UIコンポーネントからすべてのロジックを簡単に分離します（ recompose を参照）。
- 簡単に作れます。
- レンダリングの前にコンポーネントを操作します。
HOCの短所
- 名前の衝突-2人のHOCが同じ名前の小道具を使用して設定できます。
- React domは巨大です。
- 親の小道具が変更されるたびに、子が再レンダリングされます。これはReactのデフォルトの動作ですが、多くのHOCがある場合は注意が必要です。
- 型-コンポーネントの観点から、どの小道具と型を取得しているかを理解することは困難です。
- HOCを使用すると、特定のHOCからプロップ
xのみが必要な場合でも、すべてのプロップが子に渡されます。 - HOCのコンポーネントの小道具に依存する引数を使用するプロセスは複雑になる可能性があります
HOCs Pro＆Con both
- 変数を定義する必要はありません。HOCでラップするだけで、HOCが供給する小道具を取得できます。これにより、UIコンポーネントが小道具の名前を「推測」します。
フックの長所
- 読みやすく宣言的。
- パフォーマンス-特定の小道具が変更されたときにのみ更新されます。
- コミュニティの成長。
フックの短所
- コンポーネント内のみ-これは、渡された小道具の条件によってコンポーネントをレンダリングできないことを意味します。
- UIとロジックをすべて含む巨大なコンポーネントファイル。
私がよく見ることの1つは、コンポーネントで副作用のあるフックを使用することです。そのため、コンポーネントのテストが難しくなり、フックの私的な使用例としては適していません。
たとえば、カスタムconst {data, loading, error} = useFetch(endpointUrl)を使用してコンポーネントを作成し、レンダリングパーツで直接使用しますreturn <>{data.name}</>同じコンポーネント。
これは、私にとって、HOCのユースケースです。 HOCにデータをロードし、それをまだダンプコンポーネントのプロパティとして提供します。これにより、コンポーネントを簡単にテストでき、懸念事項を分離できます。