Open bruno-f-cruz opened 1 week ago
I just realized that there may actually be a 3rd case
For instance, consider the following workflow:
A potential pattern might be to nest these operators within a Defer
and want the visualizer output to be Button
while the output to be the Int
. I wonder if a more "Bonsonic" way to do this is to allow VisualizerMapping
to target WorkflowOutputs
. For instance:
The intended use of
Visualizer
was to be able to propagate the visualizer of the nested workflow. However, as of the last bonsai version, this behavior seems to have been broken:Here, I would expect that a visualizer for the
String
type should be propagated and not theInt
. This is probably becauseVisualizer
is of operator typeSink
. This regression bug was probably introduced in #1751 where sinks will now propagate the visualizer of the input type.I believe we should support the following 2 cases:
1. Propagation of the original sequence's visualizer
This is extremely useful for introducing side-effects after UI elements. For instance:
This should be supported by the generic
Sink
operator2. Propagation of nested workflow's visualizer
This is useful when the user wants to have a UI for the actual side effect. Moroever, as the
Visualizer
operator has its own scope, it also prevents contaminating the workflow with unnecessary subjects. This is also critical forIncludeWorkflows
with their own visualizer.This case should be handled by the
Visualizer
operator. Moreover, it would be very useful to allow a 0-inputVisualizer
overload. Essentially allowing the creation of "visualization scopes".