Create a service for joining inputs with popovers

[cchaos]

More and more, we're seeing new components that are some combination of a form control with a popover that has custom content.

To name a few that already do this:

1. EuiComboBox 🖼️
2. EuiSuperSelect 🖼️
3. EuiColorPicker 🖼️

A few coming down the pipeline are:

4. EuiSuggest (GH issue)
5. Compressed ranges

---

It would be great if we could standardize this pattern and create a global service that just takes the triggering element and the popover content and hooks up all the keyboard shortcuts and what not. This way bug fixes can be more universal and allows for easier creation of components using this pattern.

[thompsongl]

@cchaos Working on an API/assumptions doc for this before I get into code, and have a couple design questions:

Re: #1988: We discussed the need for visual indication that a popover is present for keyboard scenarios (click focus will auto open the popover). This is still valid, but I could also see auto opening, say, number inputs, or popovers that have a single element inside. Or even not caring about a visual indication because we're working with things much less complex than the color picker. Thoughts?

The screenshot in this issue has the popover "attached" to the input, but in #2179 the popover has the caret. Do you think would be variable based on size or setting? Or have you honed in on a single style?

[cchaos]

So I think you're talking about 2 different things:

1. Caret icon in the input to indicate a dropdown

2. The popover arrow that points to the triggering element

For no. 1, I think the service shouldn't need to know about this icon. It should be determined by the control itselft.

For no. 2, I only have it in the screenshot because I didn't know how to create the "attached" version.

I think this is the point of the service; to change the popover from the default behavior of having the arrow to being the fully attached version that is the same width of the control.

[myasonik]

This worries me a bit in that a lot of these different components have pretty different semantics under-the-hood even if they look similar.

@thompsongl I'd be interested to know/working with you on how this service might handle different scenarios.

I've actually been thinking about different types of overlays a lot recently and have been building a doc about it. Maybe this can be provide a starting framework going forward: a lot of words on overlays

[thompsongl]

So I think you're talking about 2 different things

Yes I am. I should've numbered them, but you correctly picked up on the distinction. Thanks!

[thompsongl]

Thanks for putting that doc together, @myasonik.
I agree that better categorization and standardization of overlay components is in order, and the discussion is likely worthy of its own tracked issue.

The 4 types you describe in the doc are apt, and I don't actually think a single service for all would be appropriate. If anything, I can see 3-4 services that share utilities but have distinct opinions on interaction. The current popover service is flexible and thus allows blurred lines.

My understanding for this immediate issue is that these compressed input popovers behaviorally most resemble type 2 ("Those that you can tab through and out of"), but they visually resemble our type 3 components (popover container attached to an input, disregarding focus location). We'll need to make clear the difference with semantics.

[thompsongl]

Started this with #2197, which will help a couple folks make progress with their features while I'm gone next week.
It currently uses our portal & popover paradigms, and as such needs more work on keyboard interaction and a11y. Just know that it is in master (unused, however) but a work in progress.

[thompsongl]

#2269 makes this thing more official.

The service itself is less of an out-of-the-box solution than this issue implies, but our aspirations were a little high given all the one-off keyboard and a11y factors. The docs get at this point and any further work can be done in more focused issues.