[🛠] Router les versions du suivi corporel sans casser les anciens Daily Reviews

✨ Résumé de GPT-5.6 Sol 　

Le récit de la découverte qu’à force de modifier l’interface du suivi corporel, les anciens billets pouvaient devenir incompatibles avec la structure la plus récente, puis du rattachement de renderer, schema et validator à une même version grâce à un unique schema_version.

body_review avait une version, mais le renderer ne l’utilisait pas

Après avoir créé un MVP de suivi alimentaire dans le blog, j’ai séparé Aujourd'hui et 7 derniers jours dans la vue repliée et empêché les cartes déployées de se casser dans les espaces étroits. J’ai aussi remplacé les étoiles blanches des verdicts de coaching par le même affichage de note que celui du suivi corporel.

En continuant à modifier l’écran, j’ai vu un problème plus important. Le front matter contenait déjà schema_version, mais _includes/body-review.html ignorait cette valeur et rendait directement la structure la plus récente. Si la structure des données changeait ensuite, les anciens Daily Reviews pouvaient passer dans le nouveau renderer et se casser.

Atteindre directement le renderer vN depuis schema_version

Je n’ai pas rempli body-review.html d’une liste croissante de case when pour chaque version. Le chemin est construit à partir du nombre, puis le fichier correspondant est inclus directement.

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

v4 mène à body-review/v4.html et v100 à body-review/v100.html. Il n’existe pas non plus de limite supérieure qui bloquerait soudainement v101. Si le fichier de cette version existe, la même règle le relie ; sinon, le build échoue au lieu de revenir silencieusement à la version la plus récente.

Garder renderer, schema et validator sous le même numéro

Versionner uniquement l’écran pouvait encore désynchroniser la validation des entrées. J’ai donc fait de chaque version un ensemble de trois fichiers.

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

Le vérificateur repère tous les vN du repository et échoue si l’un des trois fichiers manque ou si le renderer n’a pas son marqueur body-review--vN. Une nouvelle version n’est ajoutée que lorsque la structure des données doit changer, tandis qu’un billet déjà publié continue d’être interprété par la version qu’il déclare.

J’ai aussi profité de v4 pour corriger les problèmes visuels qui me gênaient. Le résumé replié place Aujourd'hui et 7 derniers jours sur des lignes distinctes, et les cartes déployées passent de trois colonnes à deux, puis une, selon la largeur du component lui-même. Le suivi corporel et les verdicts de coaching utilisent le même include de note, tandis que les textes de l’UI et les labels d’accessibilité viennent des data de chaque langue active.

Les simples changements de texte ou de style peuvent désormais rester dans v4. Si une modification casse le data shape, j’ajoute un nouvel ensemble vN. Créer un nouvel écran n’oblige plus à réécrire en même temps tous les anciens billets.