Sharing gist URLs appended to new Visualizer URL not working

[amitnovick]

Expected Behaviour:

When visiting the URL, the public gist at the appended URL should be loaded into the Visualizer and shown successfully.

Observed Behaviour:

Provided the following XState Visualizer URL:
https://xstate.js.org/viz/?gist=https://gist.github.com/amitnovick/7649b9c077e0946474712ac25d15b5b8

When visited, the console should print the following error:

Uncaught (in promise) TypeError: Cannot read property 'content' of undefined
    at machine (App.js:628)
    at utils.js:482
    at Array.reduce (<anonymous>)
    at Object.N [as updater] (utils.js:467)
    at e.resolveTransition (StateNode.js:960)
    at e.transition (StateNode.js:900)
    at interpreter.js:655
    at interpreter.js:92
    at t.nextState (interpreter.js:654)
    at interpreter.js:166

And the Loading... animation is shown instead of the usual Visualizer UI.

[amitnovick]

Thanks to @mettjus for finding this:

Potential source of the issue:
The name of the file uploaded in the gist above is FetchingMachine.js, which fails to load in Visualizer appendend URL.

The following is the same source code, uploaded in a different gist named machine.js, which succeeds to load:
https://xstate.js.org/viz/?gist=https://gist.github.com/amitnovick/8aa1caaffb383e73477f60dc4577781d

[mettjus]

Maybe this could be made overwritable via URL (i.e: &file=FetchingMachine.js).

I am thinking someone could be interested in using the same gist form many machines, maybe.

[amitnovick]

Maybe this could be made overwritable via URL (i.e: &file=FetchingMachine.js).

I am thinking someone could be interested in using the same gist form many machines, maybe.

Ah, so basically you're describing a scenario where somebody might want to upload a gist with multiple JS modules each exporting a default machine value, and have one machine import the rest and compose its' configuration with them, e.g. with src

So in that case we would want to instruct the Visualizer which module should be the entry point that should be visualized, which would be a harder to implement solution than letting the Visualizer figure out the entry point on its own.

Seems interesting for sure, but it's a feature unrelated to this issue, feel free to open an issue / PR for it if you're interested in it.

[mettjus]

I wasn't so far ahead with my proposal, even if it could be certainly possible. I am just considering, as a next step, the opportunity to have multiple machines packed into a single gist, without requiring a gist for every machine.

[mettjus]

I made a PR: #22

[mettjus]

It only addresses fetching from gist, not saving.