Track guard state behind-the-scenes when exiting, clear on re-entry

[michaelsbradleyjr]

I did an experiment trying to understand the green/red/grey visualization behavior in relation to null events and their guards:

https://xstate.js.org/viz/?gist=fbbd5dab67c92587cd726648ad1fa212

I was attempting to use a pure state.matches(...) approach but found that can't work (if the green/red behavior is desired) because when the visualizer runs the guards in the context of states to which those null events are not attached, then meta.state will be undefined.

At first I thought a solution might be for the visualizer to always pass the state, but then I realized that can lead to other problems, e.g. green might switch to red or grey if testing on state.matches(...) because the current state value may be 2+ steps removed from the state to which the guards are applicable and matching on the current state becomes ambiguous.

After experimenting with context to achieve the desired effect, I came up with an idea: that the best way to get the always-correct red/green/grey value would be for the visualizer to track the true/false/undefined value returned by the guard in a way that's opaque to the machine itself; and to reset that visual tracking upon re-entry. With such a mechanism in place it seems like it wouldn't be necessary for the visualizer to always run the guards, i.e. when they're not applicable to the current state, like it does at present. It would also avoid problems that come up with context being updated later in transitions/actions not applicable to the guards, and possibly resulting in incorrect green/red/grey toggling.

[michaelsbradleyjr]

I realized there can still be a bit of visual ambiguity:

I arrived at that visualization by event sequence: DID_START_B -> DID_START_A -> STOP.

But, visually, that looks like it could have come from STOP_A -> STOP_B, or an equivalent sequence for allStopped to have been triggered.

After experimenting with adding clearAllStored, clearAllStopped to the exits of running and stopped, respectively, it's still easy to end up with visual ambiguity.

So when any target/s of a guarded transition is exited, perhaps it should also result in clearing the tracked visual states of any logically connected guards.

I realized I confused myself earlier when interpreting what's in the screenshot — the green and red actually help avoid the ambiguity. So, I think what I proposed in the opening comment would suffice: track visual state of the guards opaquely and reset that visual state on re-entry.