内容から導いた識別子は、内容を直した瞬間に静かに外れる
peithoは各スライドに安定キーを持たせ、CSSの上書きはそのキーを的にする。
[data-slide-key="arch-1"] .slot-code { grid-column: 2 / 3; }キーは著者が明示するのが原則で、指定が無ければタイトルのslug等から導出したキーが振られる。ただし上書きの的にする価値のあるスライドには必ず明示キーを振る、という運用規則が付いている。
理由は導出キーの性質にある。タイトルを1文字直せばキーが変わり、そのキーを的にしていたCSSは的を失う。 誤字を直しただけで、当てたはずの調整が消える。しかも消えたことはどこにも現れない。
「参照が外れた」ことを検出できる形にする
peithoはさらに、存在しないキーを指すCSSセレクタをビルドエラーにする。手当てが外れたら赤く止まる。
ここで二つの手当てが重なっていることに注意したい。
明示キーにする
内容の変更でキーが動かないようにする(原因を断つ)。ただし明示キー自体を著者が改名したときには守れない。
参照の検査
それでも外れたら気付けるようにする(症状を捕まえる)。ただしこれだけでは、外れるたびに直す作業が発生し続ける。
併用が完成形という形はtypestateで壊れた状態を書けなくするの末尾と同じ構造をしている。
IaCの論理IDと同じ問題である
これはidentityは「何を同一資源と見なすか」の規則であるが扱う問題の、別領域での再演である。あちらでは識別子が変わるとstate上で別リソースになり、リファクタリングがそのまま作り直しになる。こちらでは識別子が変わると上書きCSSが的を失う。
| IaC | peitho | |
|---|---|---|
| 識別子 | resource address / 論理ID / URN | data-slide-key |
| 内容から導出すると | CDKはconstruct pathのハッシュ、Pulumiはtype/name/parentの連結 | タイトルのslug |
| 導出が動くと起きること | 別リソース扱い → Delete + Create | 上書きが的を失う |
| 手当て | ユーザ制御の識別子 / moved で写像を書く | 明示キー + 参照の検査 |
識別子を何から導くかは、リファクタリングのしやすさをそのまま決める。 内容から導けば書く手間は減るが、内容を直す自由を失う。リファクタ耐性はidentityを歴史的に繋ぐ機構が要るが扱っているのはこの交換である。