search

statelyai / xstate-tools

Public monorepo for XState tooling
183 stars 36 forks source link

Connect the inspector to the local dev server #161

Open GuillaumeAmat opened 2 years ago

GuillaumeAmat commented 2 years ago

As a user of the XState VSCode extension, I'd love to get rid of the @xstate/inspect snippet I must put in my code, in order to enjoy the awesome live inspector experience.

Is there any plan to somehow support that "live" experience in the VSCode extension?

Andarist commented 2 years ago

Are you referring to the "live" experience that you get when you are in a browser?

GuillaumeAmat commented 2 years ago

Yes, having my app running in the browser and the inspector following the current state/context/events.

As of today, I need to edit my code and the inspector opens in an iframe or a browser tab. I would love to do nothing in the code (or at least just a setting somewhere) and having the inspector in VSCode.

Andarist commented 2 years ago

I'm working on a browser extension but I'm unsure how you would like to have the live inspector running in VSCode - unless you are visiting your local webpage in a VSCode's panel or something (that is not quite part of our VS Code extension though).

davidkpiano commented 2 years ago

Just a small note: even in the future, you will at the very least have to set { devTools: true } in order to have a machine inspected.

GuillaumeAmat commented 2 years ago

I'm working on a browser extension [...]

Great! I didn't find anything related to a browser extension before creating that issue, did I miss it or is it still early/private?

[...] but I'm unsure how you would like to have the live inspector running in VSCode - unless you are visiting your local webpage in a VSCode's panel or something (that is not quite part of our VS Code extension though).

I was thinking of the other way around:

  1. If the VSCode extension detects XState in the dependencies and statecharts in the codebase, it already decorates the machine declarations. It could also create a local endpoint (e.g.: HTTP server, socket handler), and put the URI in a local conventional file (e.g.: following a naming/path convention).
  2. Codebase-wise, and if { devTools: true }, XState tries to import the "local conventional file", tries to connect to the URI, and then communicate "live" with the extension.

Just a small note: even in the future, you will at the very least have to set { devTools: true } in order to have a machine inspected.

Fair enough, and totally understandable. But IMHO, a good improvement could be to set that "globally", instead of setting it per interpretation.

E.g.: { devTools: process.env.NODE_ENV === 'development' }

When we have multiple machines in the app, or even the same page, it can be tedious to change the value here and there, instead of just having it in one place, for good.

It would "just" require having a machine selector in the extension, to choose which machine to inspect (e.g.: as we can select a specific (i)frame in the browser dev tools).