order of didTransitionCallback within nested trasition

[adriantofan]

Hello ,

I am transitioning from S1 to S2 and from within the transition I trigger an event to go back to S1. So the states are S2 followed by S1. At the and the state machine is in state S1.

If I check the order inside of didTransitionCallback the newState is S1 and than S2 and not S2,S1 as they should be.

Can you help me understand whats going on ?

Thank you

[narfdotpl]

Huh, sure.

It's an edge case. In handleEvent() I execute the transition block first, then I call the callback. In your transition you call handleEvent() without any delay, so before calling the callback, the machine performs the second transition and calls its callback first.

In general, you shouldn't call handleEvent() on self from a transition immediately. If you do, it means you already know the final state you want to be in, and therefore you should have a transition straight to that state, without any intermediate states. For example, instead of a S1 → S2 → S1 transition, you can model a S1 → S1 transition, where everything you do there is performing side effects.

I'd encourage making the change I mentioned above, but you can also make a quick fix: wrap triggering an event in a dispatch_async block.

Cheers.

[adriantofan]

Thank you for your answer.
I am not calling handleEvent() right away. Inside the transition block I execute the transition logic which involves side effects and it is rather complex. So there is no easy way to know if a new transition will be triggered.
Your solution - at least the preferred one - implies that I should move the transition logic inside didTransitionCallback because doing all the calculations in place in handleEvent is not trivial.
In this case I wonder what is a typical use case of this library and how one uses the transition block vs didTransitionCallback.
Now that you mention it the transition block looks more like a willTransitionCallback.

[narfdotpl]

The intended use case is responding to events coming from the outside of the machine, e.g. user interaction, keeping side effect code in transition blocks, and using didTransitionCallback only for notifications.

It is worth mentioning your situation (calling transitions from within transitions) in documentation. I'll add a ticket for this.

[adriantofan]

Ok, thank you, I understand better now how this library works