1. hook と普通の関数の違い
state や effect が必要な業務ロジックは hook にする。
| 普通の関数 | hook | |
|---|---|---|
useState が使える |
❌ | ✅ |
useEffect が使える |
❌ | ✅ |
| React の再レンダリングに連動 | ❌ | ✅ |
| UI に依存 | ❌ | ❌（依存しない） |
| 業務ロジック向き | △ | ◎ |
2. hook は use-case とは違う？
hook は use-case を呼ぶ側
use-case は hook を知らない
| 観点 | use-case | hook |
|---|---|---|
| 単位 | 1ユーザー操作 | 画面・フォームの振る舞い |
| 例 | 検索・保存・登録 | 初期値セット・入力補助 |
| React 依存 | ❌ しない | ✅ する |
| useState / useEffect | ❌ | ✅ |
| 再利用単位 | 機能・業務 | UI 単位 |
| テスト | Jest 単体 | Jest（hook用） |
| 呼び出し元 | Page / hook | Component |
| ボタン操作 | あり | なし |
3. custom hook のポイント
- UI（JSX）は一切含めない
- react-hook-form を「使うが支配しない」
- 状態・副作用・入力補助のみを持つ
4. 肥大化しすぎたコンポーネントをどうやって分解するか
ステップ０：まず「役割」を言語化する（最重要）
「1コンポーネント = 1責務」になるように「役割」を分割する。
（例）
-
Grid 状態管理
- rowModesModel
- rowModesRef / initialRowsRef
- 編集可否
-
業務保存処理
- Auth 依存
- 仮保存 / 確定 / 取消
- 成功・失敗行の反映
-
UI 制御
- loading オーバーレイ
- Dialog（確認）
-
表示構造
- PageHeading / Layout
- Grid の配置
ステップ 1： Hook にできない部分を固定する
以下は Hook にしません。
- JSX レイアウト
- PageHeading / Stack / Box
- Dialog の JSX（※ state は切り出せる）
ステップ ２ : Grid → 保存 → UI の順で切り出す
なぜ Grid が最初か
- UI に依存しない
- 状態と副作用がまとまっている
- 他画面再利用の可能性がある
「保存」処理は業務ルールが濃いので、テスト観点でも独立させたい。