-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Description
Currently Lens visualizations don't sync colors for same series across charts while Vislib based charts do so using the color service of the charts plugin.
To give the user more control of the inherent trade-offs of per-chart/per-dashboard color assignment, there should be a setting on dashboards to turn color sync on/off for both Lens and Visualize based charts.
Behavior
If "Sync colors across charts" is active, all charts on the dashboard using the same palette will make sure to assign the same color to the same series name even across charts. If it's turned off, each chart separately uses the palette based on the position of the series in the chart.
Rollout
Currently there's a mixture of both behaviors - Visualize charts always use the color syncing behavior while Lens charts never use it. Once the setting is introduced, all dashboards default to "on" - this means Lens charts on existing dashboards will pick up the color sync behavior. This is a breaking change and has to be documented as such. The mixture mode won't be available anymore. Both existing dashboards and newly created dashboards will default to "on".
This behavior is closest to the currently released state - in 8.0 we might change the default setting from "on" to "off" for newly created dashboards because it's a more common use case.
Tentative phasing:
- 7.11 roll out palettes service with current behavior (vislib palette is synced, default palette is not)
- (probably 7.12) Once both Visualize xy and pie charts are migrated to elastic-charts and palette service, introduce setting like described below
- 8.0 Maybe switch default from syncing to not syncing
Implementation
The setting from a dashboard has to be passed through several layers:
Dashboard
The dashboard application controls the setting - sync colors is a flag in the dashboard state similar to "Use margins between panels" and "Show panel titles". To give more flexibility in migrating the state later, it should have an explicit undefined state as default (that way we can differentiate an explicit set vs. an untouched dashboard when doing breaking changes later).
Embeddable container
The dashboard app passes the flag to the embeddable container rendering the actual panels. The container passes the flag to all embeddables via embeddable input. To do so, the default EmbeddableInput interface has to be extended. All embeddables should handle it accordingly (in some cases like saved searches this just means ignoring it).
Embeddables (Visualize and Lens)
Embeddables actually rendering charts using the palette service read the flag from the provided input and pass them to the underlying expression renderer. To do so, both loader and the expression renderer component have to be extended to take an additional property for this
Expression infrastructure
The expression infrastructure passes the flag to the expression renderer as a new property on IInterpreterRenderHandlers (similar to the "mode": #77161)
Expression renderer (Lens xy and pie renderer, Visualize xy and pie renderer)
All expression renderers internally using the palette service are responsible for fetching the flag from the provided render handlers and passing it to the actual call to the palette instance getColor method.
Palette service
The getColor method has to be extended by a new parameter as well which takes the color flag provided by the expression renderer. All individual palette implementations are responsible for using the flag making sure the same series will be color in the same way. Some palettes (e.g. gradient based palettes) can opt to simply ignore the flag. To implement the color sync, the MappedColors class can be used (currently used by the legacy vislib palette implementation as well). If the flag is set to false, both the default palette and the legacy vislib palette should fall back to pick a color based on the position of the current series in the current chart.
