When are "in state" guards appropriate?

[dminkovsky]

The docs mention:

Using "in state" guards is usually a sign that the machine can be refactored in a way that makes their usage unnecessary. Prefer avoiding "in state" guards when possible.

So, when are they appropriate?

I have some parallel machines, I am was inclined to use an "in state" guard to determine the correct response to an event in one machine given the state of a parallel machine. Not sure how I would do this without an "in state" guard, but I might be missing something.

[dminkovsky]

Looks like some info is provided here: #349 (comment)

The original purpose for the in ... state guards was to match against orthogonal child states; that is, state nodes on the same level as a given state node.

This makes sense to me intuitively: that's the use case I thought they made sense for, and after I read the above-mentioned note, I thought yeah, you could generally refactor this by adding more state, but not in my case because my states are orthogonal. Is that the idea?

[davidkpiano]

I think it might be better to show with an example. Can you share your code, and we can discuss whether the use-case is appropriate?

[dminkovsky]

Yes that makes sense @davidkpiano. My code is currently non-functioning and also complicated, so I need to reduce it to something simpler to share.

Having worked through this a bit more, though, I think the two systems are not actually orthogonal. If two sets of states and their transitions are inter-dependent in some manner, then they are not actually orthogonal right? Maybe the answer to this, too, would be best with a code example from my end, and if so, I am working to come up with one.

[davidkpiano]

Yeah, that'd be great.

Anyway, when you think of orthogonal states, it's better to think of it as the combinatorial "product" of the states in each of the orthogonal regions (by the way, "orthogonality" doesn't necessarily mean mutually exclusive; it just means that each part doesn't have side-effects in the other part; a.k.a., separation of concerns).

For example, if you have two regions (A, B, C) and (D, E), it's the same as defining states (AD, AE, BD, BE, CD, CE). Orthogonal regions just make this more concise.

In fact, I would encourage you to avoid using parallel states until you definitely recognize some sort of "combinatorial explosion", like above. With practice, you'll recognize the need for parallel states instinctively.

So for example, if we have a transition B -> C (in E), that's just a "shorthand" way of describing the transition BE -> CE, or maybe even BE -> CD.

[dminkovsky]

Thanks a lot. I appreciate the specification:

it just means that each part doesn't have side-effects in the other part

I don't believe my parallel systems have direct side-effects side effects in each other, but they are inter-related and I've found that using send() allows for a nice de-coupled approach instead of using the "in state" guard.

Also, just to confirm, you meant (see my bold emphasis):

if you have two regions (A, B, C) and (D, E), it's the same as defining states (AD, AE, BD, BE, CD, CE)

I do think I have such an "explosive" situation in my finite states, and the states involve invoking services. So, even if I tried modeling the two parallel systems as all the combined product states in one system, I don't think I could rig it up with xstate because invoking a service is not fire and forget. Using your sets above, suppose B and E invoke services. Then, I would invoke a service on both AD -> BD and on BD -> BE, and if the first invocation due to AD -> BD does not complete before BD -> BE occurs, I would not handle the completion of the first invocation. So it seems such a system must be factored into parallel systems.

Looking forward to posting the code. It's a text editor that auto-saves, but also allows inline attachments that must upload before being inserted and link previews that must be resolved. Lots going on...

[davidkpiano]

I don't believe my parallel systems have direct side-effects side effects in each other, but they are inter-related and I've found that using send() allows for a nice de-coupled approach instead of using the "in state" guard.

Yep, this is a good technique!