About statemachines? If I have certain actions, which are allowed in certain state, where they dont change it state, however those actions are async, so need to change "some" state to pending, in order to avoid multiple calls until the async is finished i.e. I have call states, for example one of which is Activated, and I have actions like MuteMic, where this action is only allowed in Activated state but lets say MuteMic is heavy / or async, so I need to surround it with pending state, should that pending state be part of the call state hierarchy, i.e. on the same level as Activated is, or somehow nested inside it, or separate state machine?,

when state == Activated
   when action == MuteMic
      state = ActivatedMuteMicPending
      effect(Effect.DoMuteMic)
      state = Activated

sealed class State {
   object Activated,
   object ActivatedMuteMicPending
}

im not sure if this is good design

The snippet with

when

can't compile to begin with

obviously, syntax is not the point

What do you want the state machine to do when it is in a pending state? If it has to wait anyway before the next action, what purpose does the pending state have? On the other hand, if the next action is independent of whether muting the mic is pending or not, I would split the muting into a new state machine. That is if state machines are the correct way to model this logic. They can get quite complex really fast unless care is taken to keep the amount of states at a reasonable amount. Also, any reason you are using a sealed class instead of an enum?

im using sealed classes because some of the states need payload, that is just a excrept

I don't have too much experience with state machines, so take everything I say with a huge grain of salt. Yes, your DisableCamera scenario is exactly what I meant. I have tried to code an example using nested separate state machines (see https://tinyurl.com/y8uqlcag). That code is definitely not ideal, but I feel like a combined top level solution (

ActivatedMuteMicPending

) would not reduce the complexity (all these combinations of action and state would still exist) and actually increase the complexity. You might be able to write an abstraction on these pending state transitions, if you have the same pattern multiple times. The biggest takeaway from this example code for me however was the fact that it feels wrong to have asynchronous state transitions. They introduce so many gotchas (e.g. my example code has shared mutable access to

state

). A more asynchronous friendly approach would be to use actors (another topic that I'm not really that well versed in). Have a look at conflated channels to see if they can help you.

why do you feel async transitions are wrong, only think I dont like about the sample is that you are doing them inside the SM, if you would call some lambda with effect enum argument, or return a effect, etc,,

Maybe I just think they are wrong because I have never encountered them. "Normal" state machines go from one state to another state directly when faced with an action. The pending state however does a transition without needing another action. That's the part I am uncomfortable with. Returning the effect sounds interesting, but then who is in charge of this effect? The caller? I'm not quite sure how that would look like. I agree that the mic SM needs to be destroyed or at least reset. In the video you linked it looks like the actions are synchronous yet independent. So I can click "Bold" and the SM for boldness toggles immediately. It does help you with composing the different functionalities and a degree of concurrency, i.e. the different SMs can be transitioned concurrently, but it does not address the issue of concurrency within a single SM. That is, if you want to cancel the muting (correct me if that is not a goal) you need concurrency in a single SM.

If you wanna be super clean you do Action.MuteMic .. and then Action.MuteMicCompleted which transitions from oending to final