[Lens] Architectural requirement: Visualizations can provide chart-level configurator

[wylieconlon]

Moving this to the top:

Decision

Visualizations should be able to provide a chart-level component (similar to #67225 for dimension editors) to provide a UI for chart-level settings.

Implementation

From a technical perspective:

We have chart-level settings which partially transfer from one chart type to the other. For the transferable settings the frame has to own the state. But the UI (the popover in the button) should be owned by the visualization to display global things which do not transfer and also display UI controls for the Lens global settings (which are transfered) in a way which makes sense for the current chart type).

Steps:

• Add an API so the visualization can provide a piece of UI in that menu
• The frame won't render anything in there
• Add frame level state which gets persisted as well, and is exposed to the visualization via frame API
• The visualization is responsible for rendering controls in the global UI component for the frame level state if it wants to but it doesn't have to
• Use the frame level state for a color theme (to be extended in the future). XY and Pie will render it, Table and Metric won't for now (as they don't use it)
• Add the legend and axis settings to the global UI, but handle the state in the visualization (it won't carry over)

The API should look similar to renderDimensionEditor (but without a columnId prop). If it is set for the current visualization, the "Chart options" button is clickable and opens a popover which contains a NativeRenderer for the new visualization API. If it's not set, the button is disabled. The editor frame manages the transferable state (in the beginning just color scheme) which is exposed (setter/getter) via the frame api and the open/close state of the chart options popover. Everything else is up to the visualization.

Discussion

We are finding a need to add extra panels to the right side editor to support different types of customization. There are two specific types of customization that are not part of the original designs for Lens.

Chart level settings:

Any setting that affects the entire chart, without being restricted to a single layer. This primarily affects the XY charts because we support multiple layers. The first setting that we want to add here is hide/show legend.

We have a fake version of this already in use for pie charts, because pie charts are restricted to a single layer:

Lens-level settings:

Some settings need to be shared even when Lens is switching chart types, most notably color palettes and other visual styling information. In my proof of concept for implemented color palettes in Lens, I placed an extra gear icon next to the chart type switcher to indicate that there are settings that affect every visualization:

cc @cchaos

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[elasticmachine]

Pinging @elastic/kibana-design (Team:Design)

[cchaos]

👍 I have this on my todo of mocks in the next couple weeks.

[wylieconlon]

@cchaos Thanks! My main ask is to get some kind of rough sketch of where you think things should go, with the least fidelity, because this affects our architecture.

[cchaos]

We have this area at the top of the canvas that shows the name of the Lens once it has been saved.

This area should just persist at all times and include a button for tiggering chart display options.

[wylieconlon]

That is definitely possible. Are you expecting that we would combine both of the categories mentioned here into the popover? For example, the popover would include shared style that affects all visualizations, as well as style that affects just the current visualization?

[cchaos]

My guess is that there is sort of some hierarchy:

• Chart level
  • Legend display
  • Label display
  • Overall color scheme
• Layer/Config level
  • Formatting
  • Color (overriding the overall color scheme)

We have to support coloring all at all levels for fine-tuned customization so it makes it hard to always be shifting where this exists. Therefore, the above proposal is more of a "customize at the top level" or "if you need to, find the config you want to change and change it there."

[cchaos]

Also that button is a simplistic version. We may not be able to put all the options in a single popover and would want to consider creating a "toolbar" of sorts.

[flash1293]

From a technical perspective:

We have chart-level settings which partially transfer from one chart type to the other. For the transferable settings the frame has to own the state. But the UI (the popover in the button) should be owned by the visualization to display global things which do not transfer and also display UI controls for the Lens global settings (which are transfered) in a way which makes sense for the current chart type).

Steps:

• Add an API so the visualization can provide a piece of UI in that menu
• The frame won't render anything in there
• Add frame level state which gets persisted as well, and is exposed to the visualization via frame API
• The visualization is responsible for rendering controls in the global UI component for the frame level state if it wants to but it doesn't have to
• Use the frame level state for a color theme (to be extended in the future). XY and Pie will render it, Table and Metric won't for now (as they don't use it)
• Add the legend and axis settings to the global UI, but handle the state in the visualization (it won't carry over)

The API should look similar to renderDimensionEditor (but without a columnId prop). If it is set for the current visualization, the "Chart options" button is clickable and opens a popover which contains a NativeRenderer for the new visualization API. If it's not set, the button is disabled. The editor frame manages the transferable state (in the beginning just color scheme) which is exposed (setter/getter) via the frame api and the open/close state of the chart options popover. Everything else is up to the visualization.