[🛠] 過去のDaily Reviewを壊さない身体記録のバージョンルーティング

✨ GPT-5.6 Solの要約 　

身体記録UIを直し続けると過去の日記が最新構造と衝突し得ることに気づき、1つのschema_versionでrenderer・schema・validatorを同じバージョンに結び付けた記録。

body_reviewにはバージョンがあったが、rendererは使っていなかった

ブログ内にダイエット・食事管理アプリのMVPを作った後、折りたたみ画面の「今日」と「直近7日」を分け、展開したカードが狭い幅でも崩れないように直した。コーチング判定の白い星も、身体記録と同じ評価表示にそろえた。

画面を直し続けるうちに、もっと大きな問題が見えた。front matterにはすでにschema_versionがあったのに、実際の_includes/body-review.htmlはその値を見ず、最新構造を直接描画していた。後でデータ構造を変えると、過去のDaily Reviewまで最新rendererに入り、壊れる可能性があった。

schema_versionからvN rendererを直接探す

body-review.htmlにバージョンごとのcase whenを並べることはしなかった。数字からパスを作り、そのファイルを直接呼び出す。

{%- assign schema_version = review.schema_version | plus: 0 -%}
{%- capture renderer_path -%}body-review/v{{ schema_version }}.html{%- endcapture -%}
{% include {{ renderer_path }} review=review %}

v4ならbody-review/v4.html、v100ならbody-review/v100.htmlへ進む。v101から急に止まる上限もない。対応するバージョンファイルが実際にあれば同じ規則でつながり、なければ最新バージョンへ黙ってfallbackせずbuildが失敗する。

renderer・schema・validatorを同じ番号で束ねる

画面だけをバージョン管理すると、入力検査がまたずれる可能性がある。そこで1つのバージョンを3つのファイルで構成した。

_includes/body-review/v4.html
_project/blog-system/body-review-schemas/v4.yml
_project/blog-system/body-review-validators/v4.rb

検査器はrepository内のすべてのvNを探し、3ファイルのどれかが欠けているか、rendererにbody-review--vNマーカーがなければ失敗する。新しいデータ構造が必要なときだけ次のバージョンを追加し、すでに公開した記事は自身が宣言したバージョンで解釈し続ける。

v4では、今すぐ気になっていた見た目も一緒に直した。折りたたみ要約では「今日」と「直近7日」を別の行に分け、展開カードはcomponent自身の幅に応じて3列から2列、さらに1列へ変わる。身体記録とコーチング判定は同じ評価includeを使い、UI文言とaccessibility labelも有効な言語ごとのdataから取得する。

これで単純な文言やstyleの修正はv4内で直せばよい。data shapeを壊す変更なら、新しいvNの一式を追加する。最新画面を作るたびに、過去の日記までまとめて書き直す必要がなくなった。