[Meta] Unify common UI components in Kibana App

[flash1293]

As the different apps of KibanaApp work with the same concepts and business objects, a lot of UI components end up looking very similar or even exactly the same. To ensure consistency and to avoid on redundant development efforts, these parts of the UI should be exposed from a central place (e.g. kibana_react).

This issue aims to collect these components and track the individual issues unifying them.

Known components

• Field icon Consumable FieldIcon component #46450
• Field list Standalone field list component #41108 (uses field icon under the hood)
• Field name (takes care of abbreviation rules, word wrapping and so on)
• Index pattern picker Create shared component for index pattern selection #47035

To discuss

• Date histogram interval picker (used in Lens, Visualize, Discover)

[elasticmachine]

Pinging @elastic/kibana-app

[timroes]

I am wondering about the package structures we are or should be using for those react components. We have a couple of options here:

(1) We expose the react components (at least if they are using a specific service) via the appropriate plugin that also exposes that service, e.g. the index pattern picker via the (data) plugin exposing the index pattern service. I think we initially dropped that idea, so we don't bind the plugins to a specific framework (react in this case).
(2) What we are currently doing: Put everything that is react into one plugin (kibana_react) from where it can be imported and used in any application. I am currently a bit concerned if we stick with that approach in the long run for a couple of reasons: (a) That plugin might grow really large over time, if it will contain anything that will be shared React code over time (that's not pure UI coming from EUI). (b) Since that plugin should not depend on any other plugin ideally (which would cause other issues), we would just export static components that the user need to wire up with the appropriate services. Might be acceptable for most cases, but perhaps there are larger components which will need a lot of wiring in the end to work? (c) I have the feeling kibana_react will turn into a new ui/public folder over time. It's not bound to any specific domain, but just to a specific framework, and as long as that framework will be our to-go-choice in Kibana we will just add more and more shared components in that. Also we are mixing very different level of components/utils in that plugin already: from just basic (absolutely Kibana independent) hooks (like useUnmount etc.), over more Kibana specific hooks (useKibana), over very very lightweight/dumb UI components (like FieldIcon) to more smart components (like Field List would be one).

I wonder what all your thoughts are about those, and if putting everything that's React into kibana_react will not lead us to a bad ui/public situation again in the future?

cc @stacey-gammon @ppisljar @epixa

[ppisljar]

for app arch we are putting large components specific to just one service right next to the service. We expose the pre-wired component on the plugin contract. This is the case with for example SearchBar or ExpressionRenderer. The idea behind kibana_react was that we offer simple components, which if they work with our services will need to be wired up by the user, as they would be statically imported.

FieldList is something that doesn't really depend on any of our services, so kibana_react feels lika a good place for now. Maybe sometimes in the future we see that the plugin has grows to large and at that time we can decide to split it, but I think we'll have better idea into what to split it to at that time/

[timroes]

Perfect, in that case I would use the same approach. Meaning we'll keep simple ui elements like FieldIcon in kibana_react, but as soon as we have dedicated UIs that are bound to specific services we can pull them into the appropriate plugins and expose them from there.

[stratoula]

All of the above components are unified now 💪