Adjusting EuiToken for use as ES field types

[cchaos]

Live build: https://cchaos-current-pr.netlify.com/#/display/icons

With the unfortunate demise of Code, we were left with the opportunity to reuse EuiToken for our need to provide a service/icon for representing ES field type (which are showcased all over Kibana and in different ways at the moment).

This PR, causes some breaking changes to EuiToken to suit these new needs, but without completely butchering the original intent (hopefully, @daveyholler).

I will start by explaining the changes I've made and then demonstrate use cases.

Changes (visual and code-breaking)

Prop changes

Before, in order to change the display of the token you had to pass an object called displayOptions which supported the keys of color, shape, fill, and hideBorder. Now, you can pass these keys directly to the EuiToken component as props.

More on the actual prop value changes below.

Color

Visual

When we test using the Tokens as they were in Discover, the colors were very bright and were a bit too Crayola. This PR subdues the background by fading it even more and decreasing the contrast of the border.

Entire list of icon before and after below.

Code

The originally accepted colors for tokens was an array of enums from tokenTint01 to tokenTint10 that were mapped to colors in a SASS map. It used a combination of brand palette, vis palette, and custom hex values. I was able to remap these colors to use all vis palette colors plus the addition of a 'gray'.

To reduce cognitive load on the consumer, however, I removed the idea that they had to remember or look for the colors of these custom tokenTint colors. Instead, they can use the vis palette naming scheme that has already been established and be found on the Colors guideline page (euiColorVis0 to euiColorVis9).

Further, EuiToken now allows consumers to pass any valid color string as the color property. If it is not one of the vis named colors, it will simply create the token version that has the fully colored background.

Fill

Previously fill was a simple boolean that, when true, would turn the normally faded background color to a non-faded (fully opaque) background color. Now, this prop is an enum supporting:

• light for the faded version
• dark for the non-faded version
• none for no background at all

Fixes

When using the fill=true it changed the icon's fill from being the color supplied to a hard-coded white. This could cause issues with contrast, so instead, the new fill=dark property, uses lightOrDarkText to determine if the text should be white or black.

hideBorder

This property has been completely removed in favor of the simple fill properties above.

However, the original border was an outset box-shadow that would turn the normally 16x16 token into a visually 18x18 token. The main issue I ran into was that this would cause the icon to get cut off if it's parent had overflow: hidden.

Example:

So instead I changed the box shadow to be inset, which maintains the visual size and fixes this problem. Though maybe the spacing between icon and and border are not as ideal.

Final changes of the original set

Only a few colors values for the token types have changed but overall kept the original design.

---

More icons

EuiToken uses a subset of icons that begin with token like tokenString. These are essentially 12x12 pixel versions of the originals. To maintain pixel alignment at these smaller sizes the glyphs themselves were tweaked. Therefore, I also had to add token (12x12) versions of:

• tokenAlias
• tokenDate
• tokenGeo
• tokenIP
• tokenNested
• tokenRange
• tokenShape

These are the ES field type tokens created for Kibana:

Example usage in Discover

I also updated EuiDataGridShchema to extend EuiToken instead of simply EuiIcon

Checklist

Will do all the unchecked list items after review in case there are major changes.

• Check against all themes for compatibility in both light and dark modes
• Checked in mobile
• Checked in IE11 and Firefox
• Props have proper autodocs
• Added documentation examples
• Added or updated jest tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[ryankeairns]

This looks great, my feedback is largely suggestions so marking as Approved.

Side note
The files weren't touched directly by this PR, but the tokens in the Tree View component seem a little smaller than they were previously, perhaps on the verge of too small.

[chandlerprall]

Changes LGTM; pulled & tested locally

[cchaos]

Jenkins, test this