Reconnect visualizations when switching their types

[vitvakatu]

Pull Request Description

Fixes #11426

Now, visualizations should no longer receive stale data props cached from previous visualizations opened on the same node. We do so by changing the visualization ID (reattaching the visualization).

This does not protect from unhandled exceptions happening inside visualizations, though, so a bigger fix will be provided separately.

switching.visualization.mp4

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[farmaazon]

It's ok if works, but I think the "reattachment" should be done "automatically" for every visualization, not only those where we call "reconnect" manually.

[farmaazon]

Could we also automatically regenerate ID always when preprocessor (expression or visualizationModule) changed? I think this should be a "general" rule, not only for visualization displayed under graph.

It may be a bit tricky to avoid recursive watch run: my idea is to make current id ref to be a tuple of (id, config); the current watch just watches this tuple, we add additional watch of configuration which sets new tuple re-using or regenerating id, and reconnect just regenerates id while keeping config. But maybe it may be even simpler.

[vitvakatu]

A few changes happened since the last review:

• We found a bug in Vue that causes an inconsistent state when updating props on custom elements components. Only one component is affected: VisualizationHost, which was the reason for the initial issue with error visualization.
• The visualization reconnection mechanism is still useful because of data caching, so I reworked it using suggestions from @farmaazon. Now, we automatically reconnect if the preprocessor (but not its arguments) changes. Also, I reduced the count of calls to executionContext.setVisualization. I believe the previous version of the code used the onCleanup callback incorrectly, causing redundant `executionContext. setVisualization (id, null) ' calls. It is unlikely a problem, but I think the intention is more explicit now. Oops, it was a mistake
• While debugging the issue, we updated vue-dev-tools version, and also implemented a little debugAccess utility function that can be useful in the future.
• We are still poorly protected from unhandled errors in visualizations, but at least we are guaranteed that any visualization will not receive unexpected stale data.

[vitvakatu]

UPD: it looks like the current implementation forgets to detach visualizations in certain cases, investigating…

[farmaazon]

To simplify usages, we could destructure props (https://vuejs.org/guide/components/props#reactive-props-destructure) - I'm not sure if it works for a second level, but event const { params } = defineProps<... should help.