[EuiCombobox] allow for multiline options of different height

[mbondyra]

Is your feature request related to a problem? Please describe. Although middle-truncation and auto-expansion alleviate most issues with long names, allowing multi-line will be a better approach in some circumstances. Our problem is specific to the users that have long field names in Kibana.

Quoting the customer: “This is very frustrating, here: we have a huge list of fields. Some fields you cannot see here, because all the prefixes are the same. What I have to do is see the HTML code and copy the field.” Right now the customer goes to Stack management and look at field names there — that's quite painful for them.

Describe the solution you'd like It'd be good to allow not to truncate at all, but instead allow multi-line options.

Desired timeline Kibana's 8.15 would be great.

[JasonStoltz]

@cee-chen Did we decide that this issue will be solve by https://github.com/elastic/eui/issues/2841?

[cee-chen]

Yes, it will! Virtualization will be able to be disabled which will allow for height: auto type configurations. With caveats of course that it's a performance cost for high numbers of options.

[teresaalvarezsoler]

I think this is important, we did everything possible on our side to visualize fields with super long names (which is unfortunately very frequent) but we need multiline with middle truncation in order to fix it once and for all.

Although, as everything, it will depend on the effort this takes, if this is a crazy project we can discuss deprioritizing it.

[JasonStoltz]

@teresaalvarezsoler Excellent, this is in our Queue for 8.16. Does that timeline work for you?

[teresaalvarezsoler]

sure, thanks!

[MichaelMarcialis]

I mentioned this in the related Slack thread, but I'll comment here as well for visibility.

I agree that supporting line breaks or multiple lines will help users to identify long fields that are currently being truncated. However, I fear it would also inadvertently create a lot of redundancy and repetition in large portions of the text strings, which will again result in difficulty reading and identifying fields.

That said, what if we were to group fields by their name hierarchy to reduce that redundancy and also use it as a means to make identification easier (regardless if truncated, with line breaks, or neither)? Here's a rough example of what I'm thinking.