Reactの22個のhookのまとめ。

5 月 30 日は React の 10 周年記念日です。 React は 10 年以上前から存在しています。![911690380596_.pic.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193270/d2167bbd-64b3-13ac-bdc5-856e39b73e18.jpeg)

Reactの最新コードをPullて確認したら、すでに 22 個のhooksがあります。びっくりした。

その中：
- reactから21個をimportされた。
- react-domから1個(useForStatus)をimportされた。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193270/1ba60aa4-461a-93a5-968c-d4166b4acd10.png)

この記事では、長年にわたるReactの開発の観点から、これらのhookの役割について説明します。

## 歴史
これまで、React の開発は主に 3 つの期間を経てきました。
- `CSR`期間（クライアントレンダリング期間）
- 兼任期間
- `RSC`期間（サーバーコンポーネント期間）

現在の22hookもこの3つの時代の産物です。

### `CSR`期間
2013 年に、jordwalke は Facebook のますます複雑化するインタラクションを解決するために React を開発しました。 React は模索期間を経て、`CSR` を満たす開発モデルを徐々に形成してきました。

この開発モデルが ClassComponent から FunctionComponent に移行された後、hookの最初のバッチが形成されました。 これらの hook はすべて `CSR` 開発モードに関連しています。 例えば：

状態の流れに関連するhook:

##### 1. useState

##### 2. useReducer

##### 3. useContext

副作用への対処に関連するhook:

##### 4. useEffect

##### 5. useLayoutEffect

運用の自由度の向上に関連するhook:

##### 6. useRef

パフォーマンスの最適化に関連するhook:

##### 7.　useMemo

##### 8. useCallback

デバッグに関連するhook:

##### 9. useDebugValue

React の進化により、いくつかの新しい hook が導入されました。本質的に、それらはすべて `CSR` 開発モデルを改善し、既存のhook機能を補完または制限することを目的としています。

##### 10. useImperativeHandle (制御不能にならないように、useRefを制御する)

##### 11. useEffectEvent (useEffect機能の補足)

##### 12. useInsertionEffect (useEffectシナリオの補足)

##### 13. useMemoCache (パフォーマンス最適化の負担を軽減する)

### 同時実行期間

2013年に、Reactが誕生した当初、Reactの作者であるjordwalke は、React が将来的に同時実行機能を開発するだろうと指摘しました。

React自体はランタイムを重視するフレームワークであるため、その反復方向はランタイムを中心に展開する必要があります。 同時実行機能は、優れたランタイム パフォーマンス最適化戦略です。

同時実行機能の実装により、2つの同時実行関連のhookが導入されました。
    
##### 14. useTransition
##### 15. useDeferredValue
    
これら 2 つのhookの本質は、更新の優先順位を下げることです。更新とはビューのレンダリングを意味するため、更新の優先順位が異なる場合は、ビューのレンダリングの優先順位も異なることになります。

これは同時実行更新の基礎です。

しかし、同時更新の出現により、React が長年にわたって採用してきた、1 つの更新が 1 つのレンダリングに対応するというモデルが崩れます。
既存のライブラリを同時モードと互換性を持たせるために、次のhookが導入されています。

##### 16. useMutableSource
##### 17. useSyncExternalStore

したがって、上記の 2 つのhookは主にオープンソースライブラリの作成者向けです。

### RSC期間
RSC (Server-side Components) は巨大なプロジェクトであり、新しくリリースされたhookからもわかるように、その実現は一朝一夕に達成できるものではありません。

これはサーバー側コンポーネントであるため、サーバー側でのコンポーネントのレンダリングが必要になります。 では、一意な識別子 (以下の id propsなど) を持つコンポーネントの場合、一意な識別子がサーバーとクライアント間で一貫していることを確認するにはどうすればよいでしょうか?

```javascript
<SomeCpn id={id}/>
```

コンポーネントが片面のみにレンダリングされる場合は、単純に Math.random() を使用して一意な識別子が取得できます。

```javascript
const id = Math.random();

<SomeCpn id={id}/>

```

ただし、このロジックがサーバーとクライアントの両方で 1 回実行されると、ID は明らかに一意ではなくなります。

サーバー/クライアント側で一意の ID を生成するには、次のようにします。

##### 18. useId

同時実行期間中は、レンダリングの優先順位の概念が導入されているため、優先順位が不十分なために`pending`のレンダリングがいくつか存在するはずです。

レンダリングの`pending`ステータスを表示するにはどうすればよいですか? React では `<Suspense>` コンポーネントが導入されています。

RSC 期間中、React チームはレンダリングの`pending`ステータスが保留中であることを発見しましたが、データ リクエストの`pending` ステータスも保留中ではなかったでしょうか?

つまり、中間`pending`状態を必要とするプロセスはすべて、`<Suspense>` の管理範囲に含めることができます。
では、`<Suspense>` の管理に含めるプロセスをマークするにはどうすればよいでしょうか? したがって、次のようになります。

##### 19. use

このhookで宣言されたプロセスの保留状態も`<Suspense>`の管理に含まれます。

`<Suspense>`の重要性がますます高まっているので、最適化する必要がありますか? <Suspense> は異なるビュー間で切り替えることができるため、これを最適化してキャッシュを増やすのは明らかに良い方法であり、次のような方法があります。

##### 20. useCacheRefresh (`<Suspense>` キャッシュを確立するために使用)
この時点で、RSC のインフラストラクチャはセットアップされており、次のステップは上位層アプリケーションを構築することです。

ブラウザ側では、`form` タグが `RSC` の概念と最も一致しており、`React` は `form` `タグの `action` 属性の周りに次の`hook`を起動しました。

##### 21. useOptimistic

##### 22. useFormStatus

これら 2 つの`hook`は、フォーム送信シナリオ (RSC とクライアント間の対話シナリオとも言えます) を最適化するためのものです。

### まとめ

`CSR`期間の`hook`はすべて開発者が直接使用するものであると言えます。 次に、同時期間の最初の 2つの`hook` (`useTransition`、`useDeferredValue`) は開発者によってほとんど使用されず、`useMutableSource` などの後の`hook`は通常の開発者によってまったく使用されません。
同様に、`RSC` 期間のすべての`hook`は通常の開発者によって使用されません。 これらは、他のライブラリおよびフレームワーク (Next.js など) 用に提供されています。
これは、React の開発の方向性が常に変化していることを示しています。


- 初期の頃は、主に Facebook 自身の問題を解決するためのフロントエンド フレームワークとして位置付けられていました。ついでにオープンソースにして、対象者は開発者でした。


- 中期的には、基盤となる `UI` ライブラリが位置づけられ、対象者はオープンソース ライブラリの作成者になります。


- 現在、位置付けは Web の基礎となるオペレーティング システムであり、対象者は上位のフルスタック フレームワークです。