Widget Visualizations with multiple input expressions

[Frizi]

Currently, the data for dynamic node widgets is requested using language server's Visualization API. That allows us to resolve method annotations using the data from evaluated method call's target. That API presents some limitations that prevents us from implementing more complete widgets in some cases.

How IDE currently queries for widgets

When the IDE receives an expression update from the language server, it uses the received methodPointer to determine the method name and a set of arguments. Then it finds appropriate target expression AST ID (see #6715 (comment)) and attaches (or updates) a visualization using following request:

{
  "jsonrpc": "2.0",
  "id": 103,
  "method": "executionContext/attachVisualisation",
  "params": {
    "expressionId": "42702ea8-dbaf-4156-b43e-6fd8b9810c12",
    "visualisationConfig": {
      "executionContextId": "ead771be-c66a-442a-9776-c80710c3623f",
      "expression": {
        "definedOnType": "Standard.Visualization.Widgets",
        "module": "Standard.Visualization.Widgets",
        "name": "get_widget_json"
      },
      "positionalArgumentsExpressions": [
        "'trim'",
        "['self', 'where', 'what']"
      ]
    },
    "visualisationId": "13117c47-91df-4993-a081-5817c965941d"
  }
}

The passed expressionId refers to the method target. In the above example that is the "-a-" expression. The positionalArgumentsExpressions contain the method name and a list of argument names to fetch the widgets for. Notably, that visualization preprocessor only ever has access to the evaluated data from the target expression, nothing else.

Proposed extension

Due to the growing requirements for more complicated widgets, this API starts being a main limitation preventing us from implementing useful widgets for some methods. For example, for widgets of Table.join method we would like to be able to use data from both joined tables.

Currently the visualization only sees the left-hand-side table, but has no access to the other one. The main culprit is that the visualization preprocessor can only ever access a single expression data as an input (the one passed via expressionId). We could lift that limitation by allowing the expression values to be queried with an enso expression, something along the lines of:

Meta.expression_value "42702ea8-dbaf-4156-b43e-6fd8b9810c12"

Then I would be able to pass that expression as an argument to the visualization prerprocessor. That would allow us to construct widget queries such that the annotation is able to operate on the values of all method arguments.

An alternative approach would be to allow the visualization to explicitly receive both "expression ID" and "raw expression" arguments. We could also fold the expressionId into that list.

A hypothetical proposed request params:

  "params": {
    "visualisationConfig": {
      "executionContextId": "ead771be-c66a-442a-9776-c80710c3623f",
      "expression": {
        "definedOnType": "Standard.Visualization.Widgets",
        "module": "Standard.Visualization.Widgets",
        "name": "get_widget_json"
      },
      "arguments": [
		  {"kind": "id", "value": "42702ea8-dbaf-4156-b43e-6fd8b9810c12"},
		  {"kind": "code", "value": "'trim'"},
		  {"kind": "code", "value": "['self', 'where', 'what']"},
		  {"kind": "id", "value": "<AST ID of 'where' argument>"},
		  {"kind": "id", "value": "<AST ID of 'what' argument>"},
      ]
    },

The issue with this approach is that now I can't easily specify an array of those expressions. Having to deal with different arities of the visualization preprocessor can quickly get pretty annoying.

[4e6]

An update to the discussion of the visualization API.

The executionContext/executeExpression method have been reworked to support executing expressions in the local scope.

interface ExecutionContextExecuteExpressionParameters {
  executionContextId: UUID;
  visualizationId: UUID;
  expressionId: UUID;
  expression: string;
}

Here the expressionId provides the scope for the expression and the expression can access the same symbols as the expressionId. I.e. if the expressionId is defined inside the main method, the epression will also see the local variables defined in the main.

[farmaazon]

@4e6 I implemented the CB preview using this endpoint. However, in the process, I discovered this API is not sufficient for me.

Currently, we read the preprocessor of the visualization (with arguments) and apply the CB input to it, constructing expressions like
Standard.Visualization.Preprocessor.default_preprocessor _ <| <cb input>. This has two drawbacks:

• I need to have an import from Standard.Visualization, otherwise I cannot to refer to it. This import is not in the default imports upon creating project.
• The "expression" part of VisualizationConfiguration does not have to be a method name; it could be a lambda, what breaks the above expression completely. I cannot think up what expression could handle both cases. Moreover, the lambda may make use of the visualization module context (like some imported type) inside.

My propositions are

• To add a "preprocessor" field to executeExpression method which work exactly the same way as visualization preprocessor (including module and arguments).
• To allow visualizations having "chain of preprocessors" where every could use different module as a context + allow such a preprocessor chains to have a local context.

[4e6]

I guess, the easiest way to fix this issue would be to include the import Standard.Visualization to the default project template. We will remove it later when the FQN resolution does not require that.