[Lens] Ability to use same buckets with different series styles

[timroes]

Currently you can configure a series style like area/bar/line only on a per layer level, but not on a per series level. That limits a use-case I've personally hit in nearly every demo I am trying to build:

Styling two series that are using the same x-axis buckets in different styles. So a common example: I split the x-axis by some terms e.g. country. Now I want on the y-axis a bar chart of average bytes and a line chart of count of documents. This is currently not really possible. The closest you can get is, that you create two separate layers on the same index, one for each of the series. Now you're having the problem, that you can't make sure the term aggregations returns the same buckets for each of the layers anymore.

There are basically two ways we can solve this:

• allowing to change the chart style for each of the series individually within one layer.
• allowing with two different layers to use a "shared x-axes bucket", meaning that behind the scenes even though it's two different layers, we use one bucket aggregation for it, so we will get the same bucket and get the same order of buckets for each of the y-axes series.

[elasticmachine]

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

[wylieconlon]

Your first idea, single-series styling, makes a lot of sense. I'm not sure I understand your second suggestion, because not all layers can use the same buckets. For example, two index patterns would not support the same buckets. I'd suggest that we focus on the first option, doing single-Y axis styling. It seems closely related to other styling requests for the Y axis, such as: #53663

[ghudgins]

workaround: create a separate layer with the same primary dimension and update chart type on the layer

@timroes can you confirm this is mostly a usability thing or am I missing some detail about what isn't possible

[timroes]

@ghudgins Yes, from my current understanding this is simply a usability issue, that I would prefer sometimes configuring series type "per series", to not need to do the workaround you described above.