概要

去年の5月ごろ.野心的な私は頭を地面にぶつけます!!!ショッピングモールプロジェクトがあります
反応を書きました...無数のクエリーセレクタと...idと...
どうせ.これは私のバニラカフェから消したい黒い歴史なので、初めてを覚えるためにずっと残しています.
この場合、少なくともすくい取ることができるのはユーザーの認可を担当する特設だけだ...
無意識に、hocはいわゆる「教母」であり、各素子に共通の認可論理を使用することを可能にする.
実際、そうであれば、論理を認めるだけでなく、他の論理も十分に再利用できるのではないでしょうか.そう思います.
あ、それでは高次成分が何なのかよく説明できません.このような結論に基づいて整理する.

Higher Order Component

From... https://reactjs-kr.firebaseapp.com/docs/higher-order-components.html
私の信念は、他人が作ったものを集めてレゴを組み立てるように(?!)これに対応して、開発者はどのサービスを使用する場合も正式なドキュメントを読むべきだと考えています.
どのようなパターン...これは同じではなく,反応素子のガイド特性に基づいて誘導されたあるパターンにすぎない.

むかし(?)私が作った高次素子です
ご覧のように、構成部品とオプションを受信し、構成部品名とオプションのboolean値で構成部品にライセンスが必要かどうかを決定します.サーバからライセンスを取得し、問題がなければ、構成部品を返します.
すなわち、伝達要素は、繰り返し使用可能な論理を実行し、結果を要素に返します.これが「高次要素」です.

HOCs vs Hook

でもちょっと待って.実は私はcustom hookに詳しいです.
再利用が必要な論理、例えば通信可能、または興味のあるものを分離するためにのみ...特定の要素のみに対するhookであってもよい.あるいはプレイヤーの承認にも必要な論理です.
異なる点がはっきり見える場合は、Context APIに値を渡すか、propsにそれぞれ渡すか.と似ています.
HOCは、特定の構成部品を組み合わせて、構成部品を一度に励起できる論理を再利用します.
しかしcustom hookは、個々のコンポーネントごとに適用される友人たちです.
複数の投稿を読む...私はそう思っています.
HOCは比較的静的ですあまりpropsを必要とせず、変更不可能な使い捨てロジックを複数のコンポーネントに重ねて使用すると、その役割に応じて機能します.
逆に、custom hookの動作は、各素子によって異なる場合があり、propsが複数または1つある場合、より有利である.
Reactを学んだときに感じたのは、コンポーネントと状態、あるいはレイアウト...正直それは重要な部分ではありません非同期トラップに陥らずに状態をよりよく管理するために、どのくらいの要素を設計しますか?重要な部分の一つだと思います.
だから結論は?

HOC든, Custom hook이든 잘못된 방식이란 건 없습니다.
경우에 맞게 알맞게 사용한다면 잘 사용한 게 될 것입니다.
단순한 문제에 대해 Custom hook을 사용한다면 자칫 빈번히 사용하게 되어 코드의 길이를 늘릴 수도 있고
어려운 문제에 대해 HOC를 적용했다가 거대한 시행착오를 겪을지도 모를 일이죠.
그러니까... 당장 개발을 하기 전에.
내가 구현하고자 하는 컴포넌트에 몇 가지 props가 전달될까?
과연 이 컴포넌트가 재활용을 할 수 있는가?
너무 과하게 공통된 로직이 개별적으로 작성되고 있진 않은가?
혹은, 유사성이 높진 않은 컴포넌트나 로직을 애써 재사용하려고 하고 있는 것은 아닌가?
에 대해서 항상 의심해야겠다!

コメントリンク

https://devcore.io/en/react/hocs-vs-hooks-what-to-use-and-why/
https://medium.com/javascript-scene/do-react-hooks-replace-higher-order-components-hocs-7ae4a08b7b58