[Discover] Improve selection of very long index pattern names

[kertal]

Currently the maximum width of the popover containing the index pattern names is 320px. There are index patterns with longer names e.g. that contain remote clusters, where the names are truncated then and this can lead to difficulties in selecting the right index pattern, here's an example:

Note: There's the same issue in Lens

[mshustov]

Do we want to add a feature request:

We are looking for a page divider functionality where a user could move it slightly to the right (e.g. max 20% of the screen width).

Or it's better to create a separate issue?

[kertal]

the question is, what page divider do they mean? if it's scaling the sidebar, this will definitely happen in the future

[plaformsre]

Hi @kertal @restrry ,

Much appreciate raising this feature request. The 20% has been a proposal based on our experience with the length (ti would work for us, but maybe not for other users).

Many thanks,
Dejan

[kertal]

@mapdegree got it. thx for the feedback!

[elasticmachine]

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

[plaformsre]

Not sure where in code this is but we found the 320px width of the Kibana drop down could be easily extended. I am surprised the value is absolute value of px vs proportion of the screen. Even with 320 pixels, it seems rather small.

[kertal]

@mapdegree I do agree that it should ideally should be adapted to the screen size!

[elasticmachine]

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

[ghudgins]

similar to the problem/solution in #103701 ...we could try to move this logic up to EUI or to something that's re-usable for this case as well

should consider implementing a common component for both lens & discover

[ThomThomson]

@ghudgins, a common component for an IndexPatternPicker would be extremely helpful!

The Controls project will need one as well, and I've been thinking about how to ensure that the behaviour is the same for controls as it is for Lens and Discover.

[flash1293]

Especially with upcoming data view related changes it would be nice to have a simple component to render instead of rebuilding. @mattkime do you think we could handle this in the similar way as the field editor popover?

The least we could do is to move a dumb component rendering it in a nice way into kibana_react.

[mattkime]

do you think we could handle this in the similar way as the field editor popover?

Sure, in so far as we can find agreement on the design.

I just received a request to have a separate title for data views. Currently, the index pattern and the title are the same thing. I suspect that implementing a separate title for data views would be a smaller (or at very least similar) effort to creating the reusable component but it would also provide other benefits.

The main obstacle to implementing a proper title for data views is simply prioritization. It'll be addressed relatively quickly if there's sufficient demand.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesUx)

[stratoula]

This is related to this #133858
As Caroline mentions there are alternatives but everything comes with its price. We think that with the custom dataview names there is now a workaround that can def help improve this problem.

I am closing this in favor of the other, as now we have the same dataview picker component in Lens and Discover and it is part of the unified search project.