初めて訪れるゲームセンターでは、営業時間と料金だけでは分からないこともある。建物内の入口の探し方や、利用前に知っておきたい案内には文章が必要になる。メモはこうした説明を載せる場所であり、8月には読みやすさと編集後の確認を考えて保存方法を改めた。

来店案内と文書編集

例えば入口への道順と利用上の注意を同じメモに書く場合、段落やリストで整理すると必要な説明を探しやすい。一つの文字列で保存すると、その構造を編集画面と閲覧画面が別々に解釈することになる。表示が食い違ったり、複数の案内が一続きになったりする余地がある。

共同編集では、以前の内容と作成者を確認する手段も必要になる。現在の値を上書きするだけでは修正の経緯が失われる。ただしメモ、公式のお知らせ、写真は同じ詳細画面にあっても作成主体と保存する資料が異なるため、保存と権限の方針はそれぞれ維持した。

文書構造とリビジョン

メモにはTiptapのJSON文書を使う。段落、リスト、強調を要素として表すことで、編集画面と閲覧画面が同じ構造を理解できる。書式を一度文字列に戻し、表示時に推測し直す必要を減らす方法である。

flowchart TD
    accTitle: メモ文書と現在の選択を分離
    accDescr: ゲームセンターは現在のメモrevisionを参照し、各revisionは文書と作成者を保存する。以前の文書も変更履歴につながる。
    A[ゲームセンターの現在のメモID] --> N[新しい文書revision]
    N --> D[文書と作成者]
    P[以前の文書revision] --> L[変更前後の履歴]
    N --> L

保存時点の文書をrevision、つまり修正版として保持し、店舗には現在のメモIDを持たせる。新しい修正版を保存しても以前の文書は残り、変更履歴から前後を確認できる。共同編集のメモと運営者のお知らせが編集機能を共有しても、作成の方針は文書ごとに適用する。

文書の検証と保存処理

自由に説明できる形式にも、扱える入力の条件が必要である。編集画面は店舗IDと文書をAPIへ送り、サーバーが書き込み権限とルート、子要素、テキスト、属性を検証する。文書容量と再帰探索も制限し、閲覧画面で処理できる資料を受け取る。

情報種別で分かれた編集メニュー。メモもゲームセンター文書の一領域として編集する。 英語の原キャプチャ。

現在と同じ内容なら既存のrevisionを返す。内容が変わった場合は作成者と文書を保存し、現在の参照と変更履歴を一つのトランザクションで更新する。新しい文書だけができ、参照や履歴が欠ける状態を防ぐためである。画面は返された文書を反映してから詳細情報を更新する。

sequenceDiagram
    accTitle: 同じ文書と変更された文書の保存
    accDescr: サーバーは文書構造と書き込み権限を確認し、同じ内容には既存の記録を返し、異なる内容には新しいrevision・参照・履歴をまとめて保存する。
    participant E as メモエディター
    participant S as メモAPI
    participant D as ストレージ
    E->>S: ゲームセンターIDと文書
    S->>S: 構造と権限を確認
    S->>D: 現在の文書を比較
    alt 同じ内容
        S-->>E: 既存のrevision
    else 異なる内容
        S->>D: 新文書・参照・履歴をまとめて保存
        S-->>E: 保存した文書
    end

編集履歴の利用と保守

利用者は段落とリストで整理された案内を読み、編集者は同じ構造で修正できる。変更後も以前の文書と作成者を確認でき、変更のない保存では既存の修正版を再利用して重複を抑える。

flowchart LR
    accTitle: 同じ文書の編集と閲覧
    accDescr: エディターと閲覧画面は保存した文書構造を共有し、変更履歴では以前のrevisionを確認する。書式を変える場合は両画面の解釈も合わせる必要がある。
    D[保存した文書構造] --> E[メモの編集]
    D --> R[メモの閲覧]
    H[変更履歴] --> P[以前のrevisionを確認]

構造化には保守も伴う。新しい書式には編集、検証、表示の対応が必要になり、過去の文書を保存する容量も増える。ファイルの公開とメモの書式拡張は個別に管理し、同じページの別のコンテンツの作成権限まで変えないようにする。

関連する記事と資料：Musecatの開発過程