Error: Unable to evaluate guard in transition for event

[amitnovick]

Description

Loading the Visualizer with machine configurations that omit a guard's implementation currently causes the triggering of an error when an attempt is made to transition through it.

Minimal reproduction:

The source Gist

The Visualizer loaded with the Gist

Suggested solution:

Implement all omitted guard implementations as a function returning true, allowing users to transition through guards.

Optionally enable this behaviour only under a configuration prop such that other consumers of the XState-Viz React component will be able to turn this behaviour off when it's not appropriate for their use-case (e.g. Browser DevTools from issue #30)

[davidkpiano]

Implement all omitted guard implementations as a function returning true, allowing users to transition through guards.

We shouldn't do this because it will do different behavior than if you were to use the exact same machine in an application. It should error out because the guard needs to be defined.

That is, why assume it returns true rather than false (which I would do)?

This ambiguity should be highlighted, and we can display some sort of error that the guard cannot be evaluated because it is not implemented.

[amitnovick]

@davidkpiano Yea I agree... true is arbitrary here, it could be false just as well.

For it to be useful, the developer must be the one to decide which value the guard should take.

Currently, it's not clear which guards aren't implemented when loading a configuration that omits them.

Ideally, the Visualizer would:

• Display which guards were omitted
• Provide a control widget (a toggle) where you can choose between true and false for the default value of each omitted guard.

[mcspud]

I think perhaps we should get some clarity on the purpose of the visualizer for this. I am currently using the "config" section of the Machine clearly to show to end users how the workflow will work, including letting them "click through" and play with outcomes/scenarios. This is being done as a tech spike at a large Australian bank, and the possibility to automatically "export" our process documentation in terms of a JSON file is pretty spectacular.

Having options, including guards halt the process flow for non-technical users is problematic. I guess its something along the lines of "Config is the schematic, and options are the implementation". It is obviously not feasible to try to demo a visualised state machine to an end user whilst having to rely on promises generated by internal bank services.

If the visualiser is intended to be used separate to that understanding/use case that would be great (and I can document it).

[amitnovick]

How about an additional tab for displaying and controlling the default values of omitted implementations?

[codingedgar]

If I chick a transition, shouldn't that mean the guard is returning true? otherwise, I would click the other transition, right? At least for the click scenario, I see the guarded transitions as two distinct transitions, I'm guessing that's not what is happening.

I'm using the viz in vscode, and there's no way (i think) to send a specific event with payload, but regardless I just want to play with the machine with clicks to make videos, as a simulation where the truth is what I click. Also for other non-tech team members, it is super useful, just an interactive diagram of what is happening based on the machine definition with strings.

I'm not sure if it is a bug, but sometimes I click a guarded transition and it takes me to another ~event~ state node that shouldn't (as if I had selected a different guarded outcome) and sometimes if I restart it works as expected, but other times it is evaluating just the same outcome from a guarded transition, and I cannot transition to certain ~event~ state node ever because the guarded transition just does not go there, it keeps choosing another scenario.