共通処理が必要になる画面

検索と店舗編集は目的が異なるが、入力を待つ処理や、Dialogを閉じたときのブラウザー資源の解放は共通する。例えば同じ終了処理の問題を画面ごとに修正すると、一部に古い動作が残ることがある。コピーが増えるほど動作をそろえる負担も大きくなる。

flowchart TD
    accTitle: 製品と共有パッケージの依存方向
    accDescr: WebCoreはUIKit・FunctionKit・DataKitを利用し、DataKitは製品に依存しないFunctionKitを利用できる。
    W["WebCoreの製品機能"] --> U["UIKitの画面動作"]
    W --> F["FunctionKitの汎用動作"]
    W --> D["DataKitのサーバーデータ"]
    D --> F

Kitは再利用する処理をまとめるパッケージである。Musecatでは表示、アクセシビリティ、時間計算、ブラウザー動作など、個別の製品機能に依存しない部分を分離した。検索対象や編集権限などの意味を決める処理は製品コードに残している。

UIKitとFunctionKitの役割

UIKitはDialog、入力、画面遷移、メディアのUI動作を提供する。FunctionKitは日時や位置の計算、ブラウザーcapabilityなど再利用できる仕組みを担う。検索語の意味、許可する操作、保存内容はWebCoreが決め、サーバーデータと認証はDataKitで処理する。DataKitから汎用的なFunctionKitを使うこともできる。

sequenceDiagram
    accTitle: 検索入力の待機とリクエストの中止
    accDescr: FunctionKitは入力待機を担当し、検索機能は取得、前のリクエストの中止、結果の反映を担当する。
    participant I as 検索入力
    participant F as FunctionKit
    participant S as 検索機能
    participant A as 検索API
    I->>F: 変更した検索語
    F-->>S: 待機後に検索語を渡す
    S->>A: 中止できる取得
    I->>S: 次の入力
    S->>A: 前のリクエストを中止
    S->>S: 有効なレスポンスのみ反映

依存は製品からKitへ向ける。共有側が店舗ルートや特定の権限を読み込むと、ほかの利用側にもその前提が持ち込まれるためである。利用側は公開された入口を使い、内部ファイルの配置に依存しないようにした。

検索入力の待機と要求のキャンセル

検索では入力のたびに即座に問い合わせず、タイピングが止まるまで短く待つことがある。タイマーの開始、前の待機のキャンセル、画面終了時の後片付けはFunctionKitで共用できる。変換途中の文字を検索するか、空欄や結果の並び順をどう扱うかは検索機能が決める。

古いレスポンスが新しい検索結果を上書きしないよう、機能側が不要な要求を取り消し、現在の検索語との対応を確認する。原文検索が失敗すればエラーとする一方、補助的なキーボード補正だけの失敗なら原文結果を残す。両方成功したときは重複を除いて統合する。

flowchart TD
    accTitle: 検索失敗の影響範囲
    accDescr: 元の検索の失敗はエラーとするが、補助的なキーボード補正の失敗では正常な元の結果を維持する。
    Q["元の検索と補助検索"] --> O{"元の検索が成功"}
    O -->|"いいえ"| E["検索エラー"]
    O -->|"はい"| C{"補助検索が成功"}
    C -->|"はい"| M["重複を除いて統合"]
    C -->|"いいえ"| K["元の結果を維持"]

Dialogでも表示と終了のライフサイクルは共用するが、未保存の内容を確認する意図や保存後の移動先は機能側から渡す。それぞれの画面の目的を読み取れる形で残すためである。

パッケージの修正と機能開発

共通の仕組みをパッケージで修正すれば、その仕組みを使う画面も同じ修正を受けられる。公開exportとパッケージ単位のテストが対応動作の基準となり、内部整理が利用側に予期しない変更をもたらす可能性を減らす。

見た目が似ている画面をすべて一つの設定オブジェクトへ集約するわけではない。製品上の意味が異なるなら部品を直接組み合わせる。繰り返す処理をまとめて管理しながら、個別機能の判断を追える構成にするためである。

関連する記事と資料：エンジニアリングの記録