6 lines
1.9 KiB
Markdown
6 lines
1.9 KiB
Markdown
---
|
|
title: Parcours — les quatre fenêtres empilées deviennent une seule
|
|
---
|
|
<span>Option A livrée, l'arbitrage tombe avec. Les trois <code>showNewOrUpdate…</code> sont supprimés au profit d'un <strong>rail d'étapes toujours visible</strong> à gauche, d'un panneau de détail à droite, et d'une question qui <strong>se déplie sur place</strong> au lieu d'ouvrir une quatrième fenêtre : la profondeur maximale retombe à <strong>2</strong> — l'éditeur, puis la traduction. Les champs sont d'abord sortis en trois widgets autonomes (<code>ParcoursFields</code>, <code>EtapeFields</code>, <code>QuestionFields</code>) — c'est ce qui a rendu la refonte possible sans tout réécrire, et ce qui resterait transposable si l'écran plein cadre revenait un jour.</span>
|
|
<span><strong>Plus de bouton « Sauvegarder » : tout part à la saisie</strong> (débounce 700 ms ; les ajouts, suppressions et réordonnancements partent sans attendre). Deux pièges du backend, trouvés en lisant le contrôleur plutôt qu'en le supposant : <code>UpdateGuidedPath</code> <strong>supprime les étapes absentes du DTO</strong>, donc le payload n'emporte que celles qui ont déjà un id — les autres attendent leur <code>CreateGuidedStep</code> et seraient dupliquées ; et comme les questions n'ont <em>pas</em> d'endpoint propre (c'est voulu, elles partent avec leur étape), leur id entier est récupéré après coup <strong>par <code>order</code></strong>, seul repère stable entre la liste locale et celle du serveur. Le parcours est créé <strong>à la première modification</strong>, pas à l'ouverture : une fenêtre neuve refermée intacte ne laisse rien en base. Si une écriture échoue, la fenêtre refuse de se fermer et le pied de page porte un « Réessayer ». 14 clés i18n FR/EN/NL, 3 retirées, <code>flutter build web</code> ✅. <strong>Reste la vérification à l'œil</strong> (DB5).</span>
|