Kibana: Better select box

[ppf2]

Currently, the drop down field list for aggregation in Visualize screen returns all the fields grouped by data type (string, numeric, etc..). It will be nice for it to be doc type aware so that if the saved search associated to the visualization has a _type filter, it will only present the fields that are relevant to that _type.

On a similar topic, having a typeahead search for fields to quickly trim down the list for selection will be helpful as well for applications that have a large number of mapped fields like telemetry applications.

[rashidkpc]

Our plan for dealing with this includes implementing Chosen for the field drop downs, however a bug in firefox's handling of flex layouts introduces some pretty serious performance problems.

[ppf2]

Yah I certainly notice the perf issue using Firefox when it tries to load all the fields into the field drop down, it pegs the cpu of the client browser machine while generating the list.

[w33ble]

Going to focus on making the input easier to use, and move the savedSearch sorting to another ticket

[trevan]

Now that Firefox handles flex layout better, should the field selector be changed back to Chosen?

[w33ble]

chosen might be an option again. ui-select is in use in the forthcoming Add Data UI, as well as in the commercial X-Pack UI, so that might be a better option now.

[tbragin]

@cjcenizal @uboness @epixa @spalger I previously heard that changing to an auto-complete type select box for metrics was attempted when Kibana 4 was under construction, but the effort was not successful. There are additional comments from Rashid above:

however a bug in firefox's handling of flex layouts introduces some pretty serious performance problems.

Do we know if these performance problems still persist? Are there alternative options/implementations we can explore? I assume we'll want to standardize on an approach / component before attempting to change a particular instance of using a select box, but let me know if i'm wrong.

The issue of metrics selection with 500-1000 fields in an index (which is not uncommon given our guidance to "denormalize everything") is an acute one for many users.

cc: @ppisljar @thomasneirynck since this problem is very acute in the visual builder of Kibana.

[epixa]

I'm not sure if the performance issues still exist, but we should take another swing at this regardless. Autocompletion combined with selection is a pretty normal form component in this day and age, so I'm confident there is a solution here that will work for us, even if we need to build the thing from scratch to do it.

[trevan]

I'm the one that filed the original issue with the autocomplete selector and firefox. Since then, the performance problems have gone away. I've even switched the field selector to use chosen in my personal branch (not on github). I could work on cleaning it up to be a pull request if you want to use chosen for it.

[Bargs]

@BigFunger might have some wisdom here as well since he worked on a nice select box for the pipeline editor.

[alexfrancoeur]

Recommended UI/UX for component below:

Once https://github.com/elastic/kibana/pull/10144 is implemented, we should be able to introduce the same component to the field dropdown in visualizations.

[snide]

Closing this issue. The design team is doing housekeeping against our attached tags and closing issues without much recent activity. Feel free to reopen if you still have issues or feel this is in error.

EuiComboBox should provide all that you need to build this functionality out. We also have working prototypes of the new viz builder rebuilding a lot of these interactions as well. It's planned and on the roadmap. Unless another team has plans on implementing this in the existing viz tools I'm closing this out.