Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EuiDualRange component #1485

Merged
merged 34 commits into from
Feb 6, 2019
Merged

EuiDualRange component #1485

merged 34 commits into from
Feb 6, 2019

Conversation

thompsongl
Copy link
Contributor

@thompsongl thompsongl commented Jan 28, 2019

Summary

Resolves #496

  • Refactor EuiRange into smaller, shareable components (no breaking changes unless you count class names)
  • New EuiDualRange that uses EuiRange[X] components
  • Move Range docs/examples out of form controls section

Checklist

  • Incorporate changes from EuiRange - onValidatedChange props #1461

  • 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

@thompsongl
Copy link
Contributor Author

thompsongl commented Jan 28, 2019

@nreese @thomasneirynck Let me know your thoughts on the API, specifically the returned value array for the 2 values on onChange. The actual input element will also have the 2 values reflected in its value attribute, but it'll appear as comma separated (we're "extending" the native behavior of the underlying form element here)

@thomasneirynck
Copy link

@thompsongl love it!

Array with 2 numbers works for me.

As for the input-element having the value, that's fine imho. That is also probably something we do not really have to worry about from a user perspective, correct? (ie. that the dual-range component is implemented using <input> seems only really relevant for testing).

@thompsongl
Copy link
Contributor Author

@thomasneirynck Great!
Yes, the use of input is mostly an implementation detail, but I didn't want to alienate folks who rely heavily on native form events (e.g., submit). I think in most cases the React prop value will be consumed

@cchaos
Copy link
Contributor

cchaos commented Jan 28, 2019

@thompsongl Let me know when you've been able to

Incorporate changes from #1461

Then I can do a more thorough review.

At first glance (not at the code) I just saw a couple of issues:

  1. I think the dual range should always showRange

  1. The width of the minimum input resizes when dragging the handles

@thompsongl
Copy link
Contributor Author

@cchaos will do.

  1. Good call on showRange. I'll default to true there.

  2. This happens because the max value for the lower range value is the upper range value. There was a maxWidth calculation in there from EuiRange based on the number of digits in max. When the upper range value changes from 3 digits to 4 digits, the size changes. To avoid the resize, we'd probably be looking at erring on the side of larger inputs. Does that work?

@cchaos
Copy link
Contributor

cchaos commented Jan 28, 2019

  1. Yes, that's correct. Whatever is the largest possible length of the value – meaning the most amount of characters.

@nreese
Copy link
Contributor

nreese commented Jan 29, 2019

@thompsongl Looks really nice. Need some error handling for when showInputs is true that does not show the range, or range handles when max is less then min

screen shot 2019-01-29 at 8 07 23 am

Since this PR refactors EuiRange so much. Should I just close #1461 and let you migrate those ideas in this PR?

@thompsongl
Copy link
Contributor Author

@nreese Yeah, I have a task in here to incorporate changes from that PR. I'm fine pulling those changes into this changeset if #1461 won't merge soon. I'm also fine dealing with the merge conflicts if we want the commit history from your work.

@thompsongl
Copy link
Contributor Author

thompsongl commented Jan 30, 2019

@nreese @chandlerprall @cchaos I've incorporated the concepts from #1461 and addressed all other feedback.

Re: Validation:

  • The range/highlight track is now hidden for invalid values
  • Tooltip is conditionally hidden for empty string value
  • isInvalid is passed to parent components via onChange (implementation differs between range and dualRange because of reliance on event)

@cchaos
Copy link
Contributor

cchaos commented Jan 30, 2019

@thompsongl

The other thing that #1461 did was to allow the inputs to be completely empty. Right now when you delete the contents it always reverts to 0 and doesn't allow the user to start typing without a beginning 0 unless they move the cursor.

Your PR:

His PR:


I will make a note to myself that we need to flesh out the docs and break apart the examples for this component. But that can come later so that we can unblock the Kibana implementation.

src/components/form/range/_dual_range.scss Outdated Show resolved Hide resolved
src/components/form/range/_dual_range.scss Outdated Show resolved Hide resolved

&__progress {
height: 4px;
border-radius: 4px;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to @snide : I'll do a follow-up PR to clean up PX values. Not sure when/why they were never variables to begin with.

src/components/form/range/dual_range.js Show resolved Hide resolved
src/services/number/number.test.tsx Outdated Show resolved Hide resolved
@thompsongl
Copy link
Contributor Author

@chandlerprall I've fixed the first 3 of your comments. Good catch on that front!

I'm working through options for the last one.

@thompsongl
Copy link
Contributor Author

Updates for the last comment from @chandlerprall

@chandlerprall
Copy link
Contributor

@cchaos
Copy link
Contributor

cchaos commented Feb 5, 2019

Hmm, there are some class changes that look concerning especially in the jest files, though I thought they looked right when I reviewed (like compressed). I'll have to take another look.

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple small things. Nice refactoring though!!

src/components/form/range/index.d.ts Outdated Show resolved Hide resolved
src/components/form/range/index.d.ts Outdated Show resolved Hide resolved
src/services/number/number.ts Outdated Show resolved Hide resolved
src/components/form/range/dual_range.js Outdated Show resolved Hide resolved
src/services/number/number.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; reviewed code changes and tested UX. Going to hold off on approval until @cchaos takes a second look at those classnames.

@thompsongl
Copy link
Contributor Author

Re: class name changes:
I should've put a comment in there from the start, but it was a Zoom conversation with @snide that had me believe that class name changes (typically) do no constitute breaking changes. After the refactor, it was clear that there were a lot more BEM Block-level components than the Sass showed originally. React component == Sass Block was my thinking.

Could be that this isn't your concern, but more context for you all, nonetheless.

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Just had a couple questions about multiple components in one file.

src/components/form/range/range_track.js Outdated Show resolved Hide resolved
src/components/form/range/range_track.js Outdated Show resolved Hide resolved
src/components/form/range/dual_range.js Outdated Show resolved Hide resolved
src/components/form/range/dual_range.js Outdated Show resolved Hide resolved
src/components/form/range/dual_range.js Outdated Show resolved Hide resolved
cchaos and others added 3 commits February 6, 2019 10:20
Name change suggestion from @cchaos

Co-Authored-By: thompsongl <thompsongl@users.noreply.github.com>
Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, Thank you! Sorry it took so long. I know others will be excited for this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a (dual) range component
6 participants