En tant que développeur frontend, on est souvent confrontés à de la gestion de _state_. Cette gestion est connue pour être rapidement difficile, surtout lorsque l'application grandie : l'état initial, les états non-attendus, les races-conditions, sont autant de raisons d'apparition de bugs. La gestion de l'état est rendue particulièrement difficile par le nombre de sources différentes qui peuvent contenir ou modifier de l'état : * appels à des APIs retournant de la donnée utile à l'application * cache local * interactions utilisateurs à l'intérieur d'un composant gérant son propre état * changements arrivant au niveau d'un composant enfant ou parent Il existe de nombreuses solutions de gestion de l'état, l'une d'elle étant méconnue : les machines à état. En utilisant des machines à état (ou _state machines_), on retire la gestion de l'état du composant (UI) pour le déplacer vers une machine dont la seule responsabilité est de maintenir un état déterministe et une logique métier ou spécifique à l'application. Pour cela, une machine utilise : * un nombre fini de noeuds (état), qui représentent les statuts possibles de l'application * un nombre fini d'événements, représentant les interactions possibles, pour chaque noeud * les transitions, qui permettent de passer d'un état à un autre et d'effectuer des changements internes à la machine * un noeud initial Les machines à états sont reconnues comme des modèles computationnel et des abstractions fiables, mais ne sont que rarement utilisées dans des applications frontend. Elles sont cependant une solution élégante pour gérer l'état d'une application (ou une sous-partie), tout en ayant l'avantage d'être framework-agnostique.

Quand on travaille sur un projet web, on a de très grandes chances de tomber sur Angular, Vue ou React. Ces frameworks sont très présents et ont fait leur preuve sur de nombreux projets. Au point qu'aujourd'hui, on ne recherche plus un développeur JS, on recherche un développeur Angular ou React. Si je te disais qu'au final le framework que tu utilises n'a que très peu d'importance. Si je te disais que tu te sous estimes en pensant n'être qu'un développeur React ? En quelques minutes, je te montrerai que tu sais faire bien plus qu'utiliser un seul framework :)