[Lens] Mosaic / mekko vis type

[alexwizp]

Closes: #104223

Summary

Expose mosaic from charts in Lens for all the great reasons in the charts PR: elastic/elastic-charts#1113

Screens

chart:

suggestions:

validation:

[elasticmachine]

Pinging @elastic/kibana-vis-editors (Team:VisEditors)

[flash1293]

@alexwizp @ghudgins As we discussed via chat, one thing we could to do to make it more obvious to the user there need to be two "slicing" dimensions is to create different groups for the two dimensions.

Right now IMHO it looks a bit weird to have a dimension group with a dimension and it still says "Required" in red.

[alexwizp]

@elasticmachine merge upstream

[mbondyra]

@elasticmachine merge upstream

[mbondyra]

I won't approve yet because it will probably have some changes about the dimension groups.

The code looks good and I tested it on Chrome and works fine. There is one thing though that might be to reconsider, not introduced in this PR, but related. When having a date histogram and switching between any pie type charts, I don't think we should remove the date histogram. We should remove it when switching between xy chart -> pie, but not pie -> donut. @ghudgins @MichaelMarcialis WDYT?

[mbondyra]

seeing the comment from Joe, this will probably change? If for some reason it would still be here(for example, we'd decide to change the messaging instead from Required dimension to Required 2 dimensions) , I wonder if it would make sense to combine it with required as requiredMinDimensionCount... Or something shorter 😅 That would require changes for all vises.

[ghudgins]

agree @mbondyra - the stripping of date histogram seems to make the most sense only from XY --> Partition chart type (and not between the partition chart types)

[alexwizp]

@elasticmachine merge upstream

[MichaelMarcialis]

When having a date histogram and switching between any pie type charts, I don't think we should remove the date histogram. We should remove it when switching between xy chart -> pie, but not pie -> donut. @ghudgins @MichaelMarcialis WDYT?

I agree with your thinking here, @mbondyra. In the case of your second transition example, I imagine the date histogram dimension should remain as a second dimension to the mosaic chart, thus avoiding the error message entirely.

[monfera]

Great work in this PR 🎉 Here's a sortPredicate function example for the first layer, lmk if there's some specific thing that makes it problematic in Kibana:

sortPredicate: ([name1, node1]: ArrayEntry, [name2, node2]: ArrayEntry) => {
  if (name1 < name2) return -1;
  if (name2 < name1) return 1;

  // otherwise, use the increasing value order
  return node1.value - node2.value;
}

or the briefer, identical

sortPredicate: ([name1, node1]: ArrayEntry, [name2, node2]: ArrayEntry) =>
  name1 < name2 ? -1 : name1 > name2 ? 1 : node1.value - node2.value

[alexwizp]

@ghudgins I've created a separate issue cause I see similar problem with all Partitions charts. #119147

If we want to implement sorting only for Mosaic, I'll do it in this PR, if not, it should be fixed in a separate one. From my understanding at least for Treemap it should work

@flash1293 fyi

[ghudgins]

it might just because of the styling but I more want to sort mosaic's first dimension than I would on the others. sounds good either way (in this issue or otherwise) but I think it'll come up if we don't fix it. all the more reason to not forget that Experimental badge :)

[dej611]

XY transitioning

I have some questions about transitions to/from XY -> Mosaic.

Say I have this XY chart defined with Top value of extension.keyword Horizontal categories, with Break down by Top values of clientip:

When switching to Mosaic the two dimensions gets mapped into Group by with the dimension Top values of clientip (previous Break down by) as inner grouping dimension here.

But if I swap the two dimension in XY and do the same transition, Top values of clientip is still set as inner grouping dimension:

Labels inside or outside?

What does it means in Mosaic context Inside and Outside? To be positions look fixed, no?

Left also a couple of minor nitpicks.

Probably the labels is the one more important to address, as for the transition it would be nice to have it fixed but we had already similar issues afaik.

[flash1293]

Not sure whether the xy transition can be easily fixed in the current code structure. As Alexey noticed this is a difficult area to work with at the moment. I would be totally fine with leaving it in the current state as the nesting is easy to change in mosaic.

[dej611]

No strong opinion on the transition one. The labels one looks more confusing.

[alexwizp]

@elasticmachine merge upstream

[dej611]

The label position has been reworked to show now a classic "Show"/"Hide" options. But, to me, this result is not particularly valuable:

It would make more sense, in my opinion, removing completely the Position label input (with labels always enabled) and keep only the Values visibility, which even when hidden still keeps some context on the grouping:

What do you think @alexwizp , @flash1293, @markov00, @ghudgins ?

[flash1293]

No strong opinion on this one, but I think I agree with you here @dej611 - I can't think of any use cases where people would want to hide the outer labels.

[dej611]

Reviewed locally in Safari with latest changes 👍

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: c31754a
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
lens	683	684	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	962.6KB	965.4KB	+2.8KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
lens	44.1KB	44.2KB	+9.0B

History

• 💚 Build #8261 succeeded 6ed82e5
• 💚 Build #8137 succeeded 64a90b4
• 💚 Build #8052 succeeded f44d388
• 💚 Build #7978 succeeded d9070dd
• 💚 Build #7902 succeeded 803c27c
• 💔 Build #7700 failed 11305e0

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @alexwizp