Selectable EuiCards

[cchaos]

Fixes #1868

This PR adds a selectable: {} prop that requires at the very least an onClick to be able to adde a "Select" button to the bottom of an EuiCard. This allows for a selectable pattern to be achieved without worrying about links that may occur inside descriptions or footers as the select button is distinct and not the entire card.

The new EuiCardSelect component is not exported via the index file as it is a component only used by EuiCard and therefore should not be found outside of EUI.

Reviewers note:

The above example and currently in the docs, I'm showing all the permutations for easier testing, however, I'll reduce the doc example to only the first row as the recommended and default usage.

Checklist

• This was checked in mobile
• This was checked in IE11
• This was checked in dark mode
• Any props added have proper autodocs
• Documentation examples were added
• A changelog entry exists and is marked appropriately
• [ ] This was checked for breaking changes and labeled appropriately
• Jest tests were updated or added to match the most common scenarios
• This was checked against keyboard-only and screenreader scenarios
• [ ] This required updates to Framer X components

[snide]

cc @gjones so he's aware he'll have some new tooling for cards.

[ryankeairns]

This looks nice, I'm sure it will get a lot of use!

A few observations, the first of which may be the only potential 'blocker':

• When clicking/toggling the selected state, the custom (not check mark) icon does not go away when the card is deselected. Given this is a key visual differentiator between states, I suspect it should not display in the unselected state (see the example with the bell icon).
  

• I'm reminded that the bottomGraphic needs to be removed since we are no longer using that design on the new home page. I have a to-do to tackle this.

• And last but not least, the most subjective piece of feedback :) Having played with the styles a little bit, a colored border (while perhaps not quite as visually appealing to some) does a better job of emphasizing the selected state. I suspect this would be most beneficial when a user is picking from multiple rows of options. Related, it seems a selected state here would translate to the card (button) being pressed. Coupling these things, the selected state could use a colored border and no shadow to provide more visual emphasis.

[cchaos]

Thx @ryankeairns

When clicking/toggling the selected state, the custom (not check mark) icon does not go away when the card is deselected.

Yes, this is on purpose. This is to show that the overrides will override all states. They can insert logic if they want the checkmark back on selected states like:

iconType: this.state.cardIsSelected ? 'check' : 'bell',

Since they have to manage the selected state anyway, this is the most explicit way for them to know when which icon will show. Otherwise it would be a mess of having to provide three full objects for all three states.

I've updated the danger example to highlight this:

---

I also pushed an example of altering the border colors. I'm on the fence with it. I think it might be too much, but maybe that's a good thing?

[ryankeairns]

My take is that the border color is valuable and makes a worthwhile impact on clarity. Given that users can use their own styling on the bottom button area, I think it's even more necessary. As in the example, the background color and icon may not switch between the selected/unselected state, so the border insures that a noticeable amount of visual differentiation will remain. Thanks for trying this out!

[ryankeairns]

👍 LGTM on the visual side. Scanned through the code, nothing jumped out at me there.

[thompsongl]

Code looks good. Pulled and tested locally, also