EuiRange and EuiDualRange fixes

[cchaos]

Bug fixing

• Gave the inputs a min-width in case of single digits. And remove shifting of inputs because they then don’t line up with other form rows
• Custom tick values now properly account for minimum value
• Fix styling of track color when not showing the range
• Top level className now applied to the top level wrapper
• Fixed prepend/append of value
• Moved dual range handles to min and max positions if the values are empty
• Dual range inputs account for both min and max for sizing

Added validations

The EuiRangeTrack and EuiRangeLevels now handle some errors of invalid steps/ticks.

Split up the docs page into more sections

Todo:

• Fix some state coloring of the dual range

@thompsongl I could use your help on the following

• Fix starting click on dual range if the value is ['', '']

• Fix dragging of handles on dual range where it doesn't seem to allow clicking on a different handle

• Value tooltip gets narrow towards max value

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 Crossing this one off because it's a bit out of scope for this PR. There is basic keyboard-only interactions though they could probably be enhanced.
• [ ] This required updates to Framer X components

[thompsongl]

Things to know for:

• Fix starting click on dual range if the value is ['', '']
• Fix dragging of handles on dual range where it doesn't seem to allow clicking on a different handle ['', '']

The thumbs/handles are not actually clickable. They are non-interactive indicators of the range values. Clicks and drags simply return a number in the range (exactly how the single range slider works) and we map it to the most relevant thumb/handle.

When empty values were not valid, this was easier because we at least had points of reference. Now we have to try to infer which of the two values (min, max) the click is attempting to change. Chances are good we won't always be correct in this.

We can get better, but right now this is the approach (set both values in the area of the click):

eui/src/components/form/range/dual_range.js

Lines 48 to 49 in ebaa1c4

	// Scenerio in which we cannot reasonably infer intention via click location due to current invalid thumb positions.
	// Reset both values in the proximity of the click.

[thompsongl]

Rather than attempt to interpret ['', ''], what if in those scenarios we:

1. don't render the thumbs
2. show a "Click to enable" message
3. on click, set the value to min and max

Users would then have a more reasonable experience with knowing disabled vs enabled, and what the intended interaction is

[cchaos]

@thompsongl Can you check out the latest commit? Basically I released the lastThumbInteraction state on change, but that also negated the need for these checks

eui/src/components/form/range/dual_range.js

Lines 63 to 76 in ebaa1c4

	// Lower thumb nearing swap with upper thumb
	if (
	(newVal === upper || (newVal < upper && thumbsAreEquidistant))
	&& this.state.lastThumbInteraction === 'lower'
	) {
	lower = newVal;
	}
	// Upper thumb nearing swap with lower thumb
	else if (
	(newVal === lower || (newVal > lower && thumbsAreEquidistant))
	&& this.state.lastThumbInteraction === 'upper'
	) {
	upper = newVal;
	}

I played around with it a bunch and I no longer get the issue I used to and it still seem to be working fine. But maybe they were trying to fix something I haven't run into.

I'll give the ['', ''] scenario some more thought, but generally I don't think we should force the user to initiate a component. We do know the bounds, so just show it to them. It's more a matter of showing the inputs as blank than the slider.

[cchaos]

My latest commit also attempts to handle the invalid state by finding whether the new value is in the upper or lower half and moving the appropriate handle to the new value, while the other handle gets moved to the opposite bound.

[thompsongl]

Latest commit fixes tooltip shrinkage

[thompsongl]

@thompsongl Can you check out the latest commit? Basically I released the lastThumbInteraction state on change, but that also negated the need for these checks

The one thing I see was re-introduced was a fix put in for the last comment here. Basically, during an "swap" there's a gap in values. If max is 50 and I overtake it with the min handle, min remains at 49, not 50. The gif in the original comment shows it best. (This is small potatoes, in my opinion, if we get better overall usability elsewhere)

My latest commit also attempts to handle the invalid state by finding whether the new value is in the upper or lower half and moving the appropriate handle to the new value, while the other handle gets moved to the opposite bound.

I think this is great. We have to make inferences somewhere, and this is the simplest place.

[cchaos]

Ahh, I see. So playing with that more closely, it weirdly works correctly while dragging left (down) but skips 1 step when going right (up).

But I'll agree that it's such a small potato that the overall bug-less experience is worth that extra 1 step weirdness. Which I honestly don't think will be noticeable or common.

[thompsongl]

@cchaos Correct about the left vs. right movement, hence the extra logic and tracking for which direction the handles were moving.
Again, I'm comfortable with the changes, especially given our statement regarding precision in the component docs.

[thompsongl]

Keyboard behavior (arrows) doesn't work correctly with empty values.
I'll take on fixing this.

[cchaos]

Thanks @thompsongl !!

Outside of that issue, this is no longer a WIP and ready for official review. 🙌

[cchaos]

cc @nreese

[thompsongl]

Keyboard support for ['', ''] added

[snide]

Did a scan of functionality and a code scan of the Sass and docs. My comments are all on the docs side. Did not look too deep at the JS.

[chandlerprall]

Lots of good stuff, changes LGTM!