Discussion moved from Issue of yed2kingly

[Sheldonfrith]

Hi again @brucou , I figured this was a more appropriate place for the discussion we were having, rather than at the bottom of a closed issue in a different repository, lol.

If you have the time I would like to hear how you would implement a specific type of behavior with Kingly:

This is not hypothetical, it is something I am trying to figure out how to implement with statecharts, and whatever architecture or library I end up following needs to be able to handle this use case fairly well...

I'm finding these sorts of architectural best practices for more complex use-cases are hard to glean from the docs from what I've read so far.

Scenario:

Imagine you have a 'share' functionality for a part of your app, which would open up the traditional mobile-style 'share' interface (allows you to share the current page, for example, with instagram, youtube, by email, or just as a link). When the user chooses their method of sharing, and clicks the action button, a request is sent off to some server (perhaps to instagram, for example). You would like to notify the user (maybe with a small popup) when that server responds, to tell them if their share was successful or failed for some reason, but you don't want the entire application to have to wait for that response. So while the response is still pending the user can perform more actions, such as closing the 'share' interface. Or they could send out another 'share' request (either to instagram again, or to somewhere else). And you also want to notify the user in the same way when these other share requests return, without, obviously, preventing the notification from the first request.

My First-Attempt Solution:

Here is how I first thought to implement this, when I was trying XState:

From the main app state-machine I spawn a new 'ShareMachine' which encapsulates the 'share' UI. Then when the user clicks to send the 'share' I spawn a 'ShareRequestResponseMachine' which starts in 'pending' state and ends in either 'success' or 'failure' (sending a notification command to the view layer for each of those final states). Every time the user clicks 'share' I spawn a new 'ShareRequestResponseMachine' to handle that request. Since in XState spawned machines are linked to the parent machine that spawned them, I add something like a 'DoneWithResponsesPending' state to the parent 'ShareMachine' which can tell the view layer to close the 'share' UI, but still allows the 'ShareRequestResponseMachine's to do their thing, and then once they have all finished, then I stop the 'ShareMachine'.

I haven't had time yet to dive into the Kingly API, so I don't have a description for how I would think to solve this using Kingly-specific concepts, unfortunately.

[brucou]

I am actually going to bed, but as you may guess from Kingly I stay away from all those spawned machine and what not, I have never felt the need for them. Anyways, I think you can do what you want simply by setting the SHARE_WAS_SUCCESSFUL event high enough in the state hierarchy. Better than words look at the chess game example, with the timer. You should be able to use the same technique used to implement the timer (so the clock ticked event here would be your SHARE_WAS_SUCCESSFUL event). It involves setting a compound state at the high-enough level, do something then return to whereever you were with a history state.

So, Cf. https://brucou.github.io/documentation/v1/tutorials/chess-game-ultimate.html

forgot to say that the losange in the graphical representation is used for transient states. So in this graph, it means that when a tick event occurs, it goes to that transient state, executes some action, and then immediately transitions to the history state, that is, where it were before prior to the tick event.

alright I am in bed now. I could be wrong, I haven't given it too much thought

[brucou]

So here is a quick draft illustrating the technique that uses the history state. So App is whatever logic your application is implementing. It can have any number of states, here there is none, as I don't know what else the app is doing and it does not really matter anyways.

So:

Hopefully it is self-explanatory. The empty small yellow square that you see is simply to aggregate the arrows as all of them have equal destination. Run the events to see if the logic represented here is correct. Then if it is correct you can implement it with any state machine library that has compound states and history states.

There is an alternative design which is to use parallel states. Kingly does not have parallel states, however you can simply create two Kingly machines and pass them the same inputs. Inputs that are not accepted by a machine will simply be ignored. It is simple enough, you have two concurrent machines receiving the same inputs all the time. Or you can use parallel states with XState. In this design, your share modal logic is implemented by a second state machine. The first machine (App) and second (share modal) are gathered into a single machine (don't have a graph there):

=====
! App !
!---------!
! Share !

The Share machine could be something like that:

The inflight id is to check that the request failure or success you receive correspond to requests that you have indeed sent.

Comparison:

• the first design has everything in a single state machine. That is easier to analyze. However, you can end up with a cluttered diagram if you have too many of these things. That can be a problem for readability at some scale. But for simple cases, it works fine (like in the chess game)
• the second design scales better but you need to be careful about synchronizing both machines and not reusing events. Here your shared functionality is fairly independent from the rest of application logic, so there is no synchronization to perform. So using this design works precisely for those cases with no or little synchronization between machines. Else you are better off maintaining a single machine.

[Sheldonfrith]

Thanks so much @brucou ! This is very helpful. I tend to lean towards more scalable solutions by default. So for your second option with parallel states I will have to think about how to handle the inter-state-machine communication.

I think one problem is recently I've been spending a lot of time studying OOP design patterns, and maybe this is a different paradigm but I'm trying to fit it into an OOP paradigm. Also work has gotten really busy so I haven't had the time I need to keep studying this.

Now that I'm sort of initiated into the world of state machines I doubt I will go back, because now I recognize that everything I'm building could almost certainly be better expressed with a statechart. So expect more from me in the future when I've got some time.

And thanks again for being so helpful!

[brucou]

I tend to lean towards more scalable solutions by default.

I understand you but they add complexity. Personally I refactor as the application grows. There is a principle called YAGNI (https://martinfowler.com/bliki/Yagni.html) that percolated over the years.

I will have to think about how to handle the inter-state-machine communication.

That's the thing: it is best if you don't have inter-state machine communication of any kind, i.e. your machines are decoupled. Else it is simpler to have them all in one machine. This is the case here (i.e. you have decoupled machines). Provided the event CLICKED_ON_SHARE_BUTTON and the likes are unique to the Share feature, the machine that implements the Share behavior is completely independent from any other machines --- machines only react to events, so if those events are not in their set of accepted events, they won't do anything. If you want to communicate with the rest of the world (including other machines), you can use events: X_WAS_SHARED_ON_TWITTER. There again, make sure this event is uniquely in the list of accepted events of the machine you want. In short, in the worse case, if you have some kind of naming scheme which prevents event and command name collision, and your machines are independent, say fsm1, and fsm2, then you can have the list of commands to execute in response to inputs e as commands = flatten([ fsm1(e), fsm2(e) ]). There is not much more than that. Now if you want from one machine fsm1 to modify the state in a fsm2 machine, well... fuse fsm1 and fsm2 in one.

Anyways, yes, keep in touch and let me know when you have any modelization questions, or any feedback on Kingly. It is not bothering me at all. If you are just starting, you should not have issues that I have not had before you, so I should be able to help somewhat.