`immediate` with no transition?

[nolde]

XState has entry actions, that are executed as soon as you enter a state.

Would it be possible to add that to robot? Maybe with an immediate that has no transition, just reducers?

I've found that this has been asked before, but it has been closed:
#93

Would you accept PR's to add that?

[matthewp]

I'd be open to it given that it doesn't add a bunch of complexity to the code. If you're reusing existing functionality but just wrapping it in a cleaner API, that could work. Let me know what you think.

[nolde]

Ah, it has been a while since I've looked into this, so my memory has faded a little.

My original idea would require a few more changes, if I am not mistaken; I remember looking into robot's code and finding out we would most likely need a new kind of transition, but that wouldn't transition; so the handling would have to be slightly different.

Currently, I have worked around it by basically having extra steps that set up data for me, then immediately transition.

[ehuelsmann]

I solve this type of problem with an additional state and an immediate transition, like you solved it, indeed. I would suggest that it fits the paradigm of the state machine better to have a separate state, since on entry of the state, the state machine might not be ready for the transitions going out of it, requiring additional work. That additional work perfectly fits the action on a transition from a "unprepared" state to a "prepared" state.

[nolde]

@ehuelsmann

My goal was more to set up context data when arriving at a particular state. Think of a wizard of some sort, that is controlled by the state machine; I would like to update my current progress when entering the states, as opposed to when I leave them. It makes it easier to control that kind of situation.

As you've mentioned, it can be worked around, but the ability to update context without a transition does not seem harmful to me.

[ehuelsmann]

@matthewp please review this:

the ability to update context without a transition does not seem harmful to me

Is this harmful in the sense that it's non-functional and therefor in conflict with the design of the library? If not, then I don't see any harm in it either.

[matthewp]

I think an API for this would still be functional.