L’état UI complexe n’est que rarement un sujet frontend isolé. Il signale souvent que le produit et le backend ne savent plus clairement qui possède la vérité du workflow.
Le frontend doit être réactif, mais il ne doit pas devenir en silence le système qui décide quelles transitions métier sont valides.
Le problème
Quand les produits ajoutent des parcours multi-étapes, les équipes codent souvent règles de statut, contrôles d’éligibilité et logique de reprise côté UI pour aller vite. Le backend continue de valider, mais le produit se retrouve avec deux modèles de workflow qui dérivent séparément.
Ce qui casse en pratique
- L’UI expose des actions que le backend rejettera parce que les gardes de transition ont changé d’un seul côté.
- Les updates optimistes montrent une progression qui finit rollbackée sans explication claire.
- Des composants réutilisables embarquent une logique de workflow spécifique au produit qui aurait dû vivre dans le contrat backend.
- Le support reçoit une capture d’écran qui contredit l’état backend parce que l’interface affichait encore une hypothèse obsolète.
Décisions de conception
- Garder la vérité du workflow côté backend et laisser l’UI consommer des actions autorisées explicites.
- Préférer des modèles de statut et de capacités fournis par le serveur à des arbres de conditions purement frontend.
- Rendre explicites dans l’UI les états async afin que l’utilisateur distingue
accepted, processing et completed.
- Utiliser des tests de contrat ou des snapshots basés sur fixtures pour détecter la dérive frontend/backend avant release.
Arbitrages
- Le frontend perd un peu d’autonomie locale en échange d’un comportement workflow plus fiable.
- Des contrats API plus riches exigent davantage de coordination entre produit et backend.
- Des états pending et recovery explicites ajoutent de la complexité UX, mais évitent les interfaces trompeuses.
Patterns de production
- Réponses basées sur capacités listant les prochaines actions autorisées.
- États UI distincts pour
accepted, queued, running, failed, completed.
- Tests de contrat autour des payloads de workflow et de leur rendu UI.
- Correlation IDs visibles en support lorsque l’état UI et l’état backend divergent.
Ce que je ferais différemment
- Introduire plus tôt des fixtures de transition partagées entre frontend et backend.
- Traiter les libellés de statut comme un sujet de contrat, pas de simple copywriting.
- Construire plus tôt des vues de réconciliation support pour résoudre rapidement les désaccords d’état.