-
Notifications
You must be signed in to change notification settings - Fork 352
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
feat(Slider): Added new slider component #5358
Conversation
PF4 preview: https://patternfly-react-pr-5358.surge.sh |
Codecov Report
@@ Coverage Diff @@
## master #5358 +/- ##
==========================================
- Coverage 52.24% 52.15% -0.10%
==========================================
Files 575 577 +2
Lines 11044 11173 +129
Branches 4116 4162 +46
==========================================
+ Hits 5770 5827 +57
- Misses 4538 4609 +71
- Partials 736 737 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this, we look forward to this feature in cockpit.
I quickly tried it out, I have some pointers for improvement.
- Keyboard interactions don't work
- Clicking on random place in the slider should move the current position there
Tried it on firefox-83.0-13.fc33.x86_64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good @tlabaj . Just had a couple of issues/questions.
- For the continuous slider I notice that it never returns fractional values. Should we allow the consumer to set precision via a prop? There might be cases where you don't want the returned value always rounded to a whole number.
- For the "Thumb value input" example, I was able to get the thumb and value input to disappear from view by entering a value beyond the upper limit of the slider. Seems like there should be some value checking to make sure the slider value can never exceed the upper or lower limits.
- The keyboard interaction worked for me except on the last example of the slider with actions. @KKoukiou how were you expecting the interaction to work. We specified that the slider value should only change upon pressing Enter or tabbing out of the field. Not on every keystroke.
- Agree with @KKoukiou that you should also be able to update the value by clicking on the slider bar.
I expect that clicking on the circle of the slider and then using my right and left keyboard keys, should move the slider value left and right accordingly. This does not happen for me at least.
|
It does return the fractional value. The demo code takes the floor and displays that. I can update that if you like.
For this one, are you talking about both the sliders in the action example or the very last one. I could not reproduce an issue with the keyboard interaction other than what was mentioned about clicking on the slider and clicking the thumb to apply focus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice job with this so far, Titani!!! 🎉 ⭐ From my perspective, I think the keyboard interaction looks pretty good so far, and I think handling the aria position with the aria-valuetext
was a decent way to do it.
The only thing I've noticed that I thought was a little odd is that I can't seem to get the slider to 0 for a lot of the examples by keyboard, though it looks like this is true by mouse as well for some. Is it intentional to enforce a minimum value like that? Wondering if some of them may be a tad odd though. For example, if you're looking at the discrete example and the slider thumb starts at 2 and you drag it to 0, the slider value above it stays at 2 (I noticed this is true if it starts at any number and you drag it to 0, it will always stay at the previous number).
Yes, I'm talking about the very last one. If I change the value in the number field and hit Enter or tab out of the field, nothing happens. I'm having the same problem with the second example under Value input. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Looks like you fixed the thing I was seeing before. 🙂
onFocus={onInputFocus} | ||
onBlur={onBlur} | ||
/> | ||
{inputLabel && <span className={css(styles.inputGroupText, 'pf-m-plain')}>{inputLabel}</span>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically an <InputGroup>
is only needed here if this text exists, but it doesn't hurt to leave it the way it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also curious why you don't use <InputGroupText>
for this element? Looks like we would need an enhancement for isPlain
or something to apply .pf-m-plain
.
I can open a separate issue for that enhancement if we don't want to do it here. It was added as part of patternfly/patternfly#3711
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated this to use iInputGroup, InputGroupText
and TextInput
. It was an oversight.
The InputGroupText
component still need to be updated for the plain variation. @mcarrano do you want me to open a new issue to make that update? The style is still applied inline here so it still displays correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Go ahead and open a core issue @tlabaj .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}; | ||
|
||
const inputGroup = ( | ||
<div className={css(styles.inputGroup)}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious why you don't use <InputGroup>
here?
|
||
const inputGroup = ( | ||
<div className={css(styles.inputGroup)}> | ||
<input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why you don't use <TextInput>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Left some questions, but they shouldn't hold up merging this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making those updates @tlabaj . Looks good to me!
Looks good, just two interaction questions. In the In the |
I see the issue.
|
Right. There is no disabled styling for the Slider. We could add that but I'm hesitant as there is not a product use case for it. Can you just disable events on the slider for now @tlabaj to make this example work better? |
@mcarrano I could. However, I don't think that is a good idea. I think that could be confusing to the consumer since there is no visual indication that the slider is disabled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd be fine with it either way. Since this will be a beta component we can update the example later if we leave it in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I only see this on the actions example so it might just be that example's issue, but I noticed that when I try to navigate the actions example, it doesn't quite behave right (tring to use the right arrow key on the thumb doesn't work, only the left) and when I try to use the increase/plus button, it adds on a bizarre increment:
currentValue?: number; | ||
/** Flag indicating if the slider is is discrete */ | ||
isDiscrete?: boolean; | ||
/** Array of slider step objects (value and label of each step) for the slider. If this is provided, the numSteps prop will be ignored.*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there still a numSteps
prop? I dont see it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope. that was removed
we should also open an issue to make the sliders work on mobile. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM on the accessibility side! 🙂
@nicolethoen there is already an issue open for that. #5363 |
Your changes have been released in:
Thanks for your contribution! 🎉 |
What: Closes #5187
TODO: integration tests