Fixed an issue with machines created by `withConfig`/`withContext` not being captured

[Andarist]

trafficstars

fixes https://github.com/statelyai/xstate-viz/issues/300

but... the console output after the fix is:

in-config log
withConfig log
in-config log

that is because we capture 2 machines here (and this is somewhat an expected result as per https://github.com/statelyai/xstate-viz/pull/214, just not really in this case). This shows the limits of the current eval-like approach. It's basically impossible to cover common scenarios correctly without static analysis, cc @davidkpiano

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: d3301379fd95b1af11c939946a691bc9ff26699d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel[bot]]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/statelyai/xstate-viz/Bf758rUEPCyTEf5KPZKn9exfctKF
✅ Preview: https://xstate-viz-git-andarist-fix-300-statelyai.vercel.app

[davidkpiano]

This shows the limits of the current eval-like approach. It's basically impossible to cover common scenarios correctly without static analysis

The other solution here is to opt into reading from inspect(someMachine).start(), then interpreted machines can be visualized the same as how inspected machines are.

[Andarist]

The other solution here is to opt into reading from inspect(someMachine).start(), then interpreted machines can be visualized the same as how inspected machines are.

Yes, we could differentiate the behavior based on the interpret calls being in the source file but that's kinda a hidden feature, people wouldn't easily realize the difference on their own.

Either way - this probably ain't a discussion for now. While this is gonna be slightly surprising - it's better than not supporting withConfig at all, right? 🤔 cc @mattpocock

[davidkpiano]

The other solution here is to opt into reading from inspect(someMachine).start(), then interpreted machines can be visualized the same as how inspected machines are.

Yes, we could differentiate the behavior based on the interpret calls being in the source file but that's kinda a hidden feature, people wouldn't easily realize the difference on their own.

Either way - this probably ain't a discussion for now. While this is gonna be slightly surprising - it's better than not supporting withConfig at all, right? 🤔 cc @mattpocock

Yep, this solution works for now

[mattpocock]

@Andarist could we compare the config objects we receive and deduplicate them? That would prevent the doubling of logs.