Les interfaces graphiques en tant que machines d'états finis

On délègue encore trop souvent la gestion de l’état à des usines à gaz type Redux ou Context API, alors qu’on a déjà une machine d’état native dispo depuis 30 ans : l’URL.

Mais voilà, beaucoup continuent de mettre tout le state en mémoire (par exemple dans un useState) sans se demander si le navigateur peut pas le gérer à leur place.

Et dès que tu rafraîchis, tu perds tout, le bouton “retour” casse l’expérience, et l’utilisateur se tape des trucs à reconfigurer à la main.

Le pire, c’est que parfois même les URLs sont là, mais c’est du charabia incompréhensible, surchargé ou mal structuré. Bref, l’opacité ou l’amnésie complète de l’UI, tout sauf une machine d’état fiable.

À l’inverse — ce que décrit cet article — ce qui fonctionne parfaitement avec ce principe, c’est que l’URL est utilisée comme un vrai état sérialisé.

Chaque changement dans l’interface met à jour l’URL, chaque URL représente un état précis de l’appli, et surtout chaque état est réversible, partageable, persistable.

C’est clair, lisible, logique.

La navigation dans l’UI devient équivalente à la navigation dans une machine d’état : chaque segment du path, chaque query param encode une transition.

Tu peux même lire l’URL à froid et savoir dans quel état l’UI va se retrouver, comme si tu lisais un diagramme d’état.

C’est simple, efficace, et ça respecte la promesse initiale du web : back button, partage de lien, bookmark, tout fonctionne.

‍