# GUIポリシー

画面の組み立て、状態の置き場所、表示部品から処理担当へ操作を渡す経路、現在状態による判断を確認する。

## 判定基準

許容構成は、画面・領域に対応するフレームワーク標準の状態保持実装、画面専用hookによる実装分割、採用済みの状態管理・取得基盤の利用、または独立した状態所有者を必要とする共有・寿命の要件に基づく構成である。画面の再描画をまたいで保持することや、画面内の複数部品が使うことだけでは、独自の状態所有者を新設する根拠にならない。

| 基準 | 判定 |
|------|------|
| 許容構成に該当しない独自の状態保持・操作処理層を新設し、画面内の状態と操作判断を移して、画面を委譲と描画だけにする | REJECT |
| 複数部品が同じ対象の識別子を別々に持ち、表示や操作の対象がずれる | REJECT |
| 表示部品が特定画面のAPIを呼び、処理後の遷移や結果まで決める | REJECT |
| 操作の可否を左右する状態を確認せず、受け付けられない操作やその処理を実行する | REJECT |
| 受理した操作の処理結果を次の状態や結果表示へ反映しない | REJECT |
| 処理済みまたは拒否した操作を上位がもう一度実行する | REJECT |
| 確認への回答を待たず、判断の前提となる対象・入力・保存状態を変える操作を実行する | REJECT |
| 仕様が許可または必要とする、確認対象に影響しない独立した操作まで確認待ちの間一律に停止する | REJECT |
| クリック、キーボード、フォームなどの入口が同じ状態判断を通らず、処理中に同じ処理や競合する操作を再送信できる | REJECT |
| Rootである画面（Webではページ）と独立領域がMediatorを担い、その画面・領域に対応するフレームワーク標準の状態保持オブジェクト（ViewModel、参照型の状態所有者など）、画面専用hook、標準state/reducerで実装する。専用の状態機械は要求しない | OK |
| 純粋関数・reducerで検証・一覧の追加や合算・差分判定・価格計算を行い、通信だけのAPI関数を分離する | OK |
| 許容構成の範囲で利用範囲・寿命に合うProvider/storeと採用した取得キャッシュ基盤を使う。画面が値と操作を作りProviderで画面内へ配る構成も含む。画面ローカルの編集状態は原則画面に置き、サーバーデータの取得キャッシュと区別する | OK |
| 部品内だけで使う入力値や開閉状態を、その部品が持つ | OK |
| 表示部品が値を表示し、操作の意図を上位へ通知する | OK |
| 画面や領域のコンポーネントがMediatorとして現在状態と対象を確認し、操作の受理または拒否、処理の開始、次の状態、表示内容、操作可否、表示対象と処理対象の整合を裁定する | OK |
| 部品が担当しない操作だけを上位へ順に渡す | OK |
| 確認待ちで、確認と取消の操作を受理し、それぞれの結果を状態へ反映する | OK |
| 処理中に同じ処理の重複実行や競合する操作は止め、影響しない独立した操作は仕様に応じて続けられる | OK |

名前は問わない。標準の購読APIでの接続や改名だけでは標準構成に該当しない。別の独自状態所有者へ委譲するだけのhookも、画面専用hookによる実装分割には含めない。

## 例

```text
NG: 共通の表示部品が、操作を受けると特定APIを呼び、
    処理後のURLまで決める
    → 別の画面で使うたび、特定の通信と遷移を受け入れることになる

OK: 画面がRootのMediatorとして状態と操作判断を持ち、独立した各操作領域のコンポーネントも子のMediatorとして自分の入力と処理状態を管理して操作を判断する。
    表示部品はその領域へ意図を知らせ、共通の説明画面を開く操作は親へ知らせる。

NG: 入力の破棄を確認している間に、別の入口からその入力の保存を始める
    → 確認の前提だった未保存の内容が変わる

OK: 画面や領域のコンポーネントがMediatorとして確認待ちの状態を見て保存を拒否し、確認への回答を待つ

NG: 許容構成に該当しない、画面とは別に新設した独自の状態保持オブジェクトが画面内の状態と操作判断を持ち、画面は委譲して描画するだけである
    → 状態と操作判断を画面のMediatorの実装へ戻す

OK: 画面が状態と操作判断を持ち、純粋関数で計算する。
    画面固有の型・API・状態を扱う画面専用hookへの実装分割もできる。
```