Quick way to debug machine object?

[dsngo]

I have been using xstate for awhile, absolutely love it. It has changed the way I think about asynchronous/synchronous operations. However, as my programs are less likely to run into impossible bugs, I personally have ran into a ton of time consuming xstate cryptic bugs message (ie. type of undefined from some big/not yet refactored machines, StateNode invalid, etc and a lot more) without pointing to the problem but only to the start/beginning of the great createMachine object. Some might say TS solves all of my problems, I agree it might help but not all project has the luxury of being written/configured in TS.

I do not know if there is a better way to combat this, as my state machines are getting more features, more complex, I feel a great hesitation to touch or even look at them.

Would love to hear from you guys.

[davidkpiano]

Do you have any reproducible examples of some weird errors that you're getting? That would help with this discussion.

[dsngo]

I have resolved most of them, and that process really took a long time consider I had to go through every line of the machine to determine what was wrong. For example, some invalid StateNodes would only log type of undefined without pointing to anywhere, ie invoke property that has src typos, etc. Actions properties that only contain boolean value (come from dynamically created machine) also cause cryptic error as well, etc.

I am afraid that after resolving these simple but tiresome errors, I just want to forget them, so currently there is no reproducible sample. But it is easy to reproduce as you just put some invalid statenode, putting stateNode where you need action, putting another invoke inside invoke src, etc.

The point is is there a tool/way to get to the error quicker from xstate without the need to look through them line by line.

[davidkpiano]

Honestly, TypeScript would be the biggest help here. If you're using VS Code, you can add // @ts-check to the top of your file(s) containing your machines and get some useful "type checking" that will point out obvious errors.

Other than that, I have to make some static analysis tools to help.

[dsngo]

The problem with ts-check is that users still have to create his own types check, this is feasible with small project, but I assume it would also add another time constraints to the developers.
If xstate had a small static analysis tool for just valid machine object check, that would be perfect. I personally find that the biggest barrier of xstate to newcomers is that when using with xstate, the complex of statenode/actionobject/meta properties produces quite a big confusion. That tool might just allow them to know where it fails and ultimately shorten the learning process.

[Andarist]

Such a tool is actually on my mind but it still would be TS-based. Since TS compiler is able to analyze some JS code it maybe will be possible to add some static analysis for JS alone but we’ll have to see how this playa out. You are also mentioning creating some machines dynamically - this has very low change of working with static analysis tool