Supporting the ability to have `_enter` and `_exit` actions.

There are many state machines where you need to execute an action on entry into that state. This is especially important for more complex state machines where there may be multiple transitions (from different states) that go into a particular target state. In those cases, you would end up having to write the same code in multiple transitions, which makes maintenance more difficult. Instead, an _entry (or other reserved) action would allow the actions to be consolidated to one place. This also applies for when exiting a state.

I’ve been able to implement it quite easily (not sure if it is completely correct, since I am bypassing the middleware layer).

What are your thoughts?

[krasimir]

Very good discussion. I have the feeling that adding @enter and @exit will be a good addition to the library. I’m not sure about the API and how the machine will handle/expose those new methods. Will think about it.

[rkoshy]

@illarionvk I don’t disagree that your method will provide the same end result. However IMHO, from the perspective of readability and understandability, having the entry/exit in the state machine makes it much more obvious that “things” are happening on exit/entry

I go through many hoops to actually send all activity by the user or by the system into the state-machine so that the behavior of the app is completely under the control of the state machine. So then, if I introduce this “side-bar” type behavior where someone is “watching the state machine” and making further changes to the state of the app, UI, etc… I think it’s counter-intuitive and defeats the goal of the state-machine being the “controller” of state.

As for UI – I’m using a completely decoupled eventing model to ensure that the state-machine is not dependent on the UI or vice-versa - I’m actually converting some C++ code that I wrote about 15 years ago. So while the app is in Angular, all the components subscribe to events that tell them about the state of affairs, and they render themselves or remove themselves accordingly.

For instance, if you compare (after removing other transitions, for comparison here)

        Wrapup: {
          _entry: (fsm, previousState) => {
            this._pubsub.publishEvent(ADEvents.EVENT_VOICE_SESSION_WRAPUP, fsm.sessionData);
          },
          ....

to

    Wrapup: {
           ....
    }

the former makes it clear that something will happen immediately on entry into Wrapup.