La force de ce pattern pour décrire un screen flow, c'est qu'une "Action | Transition" peut-être agnostique de son état de départ.
Résultat, tu peux très facilement créer des actions qui vont manipuler ta machine à état et l'utiliser depuis différents endroit .
Par exemple:
Action: "Editer une fiche client"
Cette action crée un état "fiche client" avec l'état précédent en paramètre.
L'état "fiche client" supporte alors une action ActionBack qui permet de revenir à l'état précédent.
Tu peux alors plugger ton action éditer la fiche client dans tous les écrans qui ont un client sélectionné.
Sans ajouter de code, tu peux alors revenir sur l'écran de départ.
D'une certaines manières, VueX reprend un peu ce principe.
# J'ai aussi beaucoup utilisé un pattern similaire
Posté par syj . En réponse au journal Sunday Python Pattern : Une machine à état toute simple. Évalué à 2.
Pendant des années , j'ai utilisé un pattern similaire. Il y a encore des traces sur ce projet sourceforge.
https://sourceforge.net/projects/planningrh/
Spécialement, le framework associé à ce projet.
https://sourceforge.net/p/planningrh/code/HEAD/tree/stateengine/
La force de ce pattern pour décrire un screen flow, c'est qu'une "Action | Transition" peut-être agnostique de son état de départ.
Résultat, tu peux très facilement créer des actions qui vont manipuler ta machine à état et l'utiliser depuis différents endroit .
Par exemple:
Action: "Editer une fiche client"
Cette action crée un état "fiche client" avec l'état précédent en paramètre.
L'état "fiche client" supporte alors une action ActionBack qui permet de revenir à l'état précédent.
Tu peux alors plugger ton action éditer la fiche client dans tous les écrans qui ont un client sélectionné.
Sans ajouter de code, tu peux alors revenir sur l'écran de départ.
D'une certaines manières, VueX reprend un peu ce principe.