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

feat(Slider): Added new slider component #5358

Merged
merged 12 commits into from
Jan 25, 2021
Merged

Conversation

tlabaj
Copy link
Contributor

@tlabaj tlabaj commented Jan 22, 2021

What: Closes #5187

TODO: integration tests

@patternfly-build
Copy link
Contributor

patternfly-build commented Jan 22, 2021

@codecov-io
Copy link

codecov-io commented Jan 22, 2021

Codecov Report

Merging #5358 (12b2d7e) into master (4f199c4) will decrease coverage by 0.09%.
The diff coverage is 44.18%.

Impacted file tree graph

@@            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     
Flag Coverage Δ
patternfly4 52.15% <44.18%> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...ckages/react-core/src/components/Slider/Slider.tsx 41.32% <41.32%> (ø)
...es/react-core/src/components/Slider/SliderStep.tsx 87.50% <87.50%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24739d0...12b2d7e. Read the comment docs.

Copy link
Collaborator

@KKoukiou KKoukiou left a 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.

Copy link
Member

@mcarrano mcarrano left a 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.

@KKoukiou
Copy link
Collaborator

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.

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.
I just tried on all browsers i have available, firefox, chrome, edge and epiphany, its' the same everywhere.
Let me know if you still can't reproduce it.

* Agree with @KKoukiou that you should also be able to update the value by clicking on the slider bar.

@tlabaj
Copy link
Contributor Author

tlabaj commented Jan 22, 2021

Thanks @KKoukiou and @mcarrano You are right, you have to tab into the thumb to be able to move it. I will work on that update and clicking on the slider to update the value.

@tlabaj
Copy link
Contributor Author

tlabaj commented Jan 22, 2021

@mcarrano

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.

It does return the fractional value. The demo code takes the floor and displays that. I can update that if you like.

  • 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.

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.

Copy link
Contributor

@jessiehuff jessiehuff left a 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).

@mcarrano
Copy link
Member

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.

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.

jessiehuff
jessiehuff previously approved these changes Jan 22, 2021
Copy link
Contributor

@jessiehuff jessiehuff left a 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>}
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Member

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 .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mcarrano it is a react issue. Core already made the update.
here is the new issue
#5367

};

const inputGroup = (
<div className={css(styles.inputGroup)}>
Copy link
Contributor

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
Copy link
Contributor

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>?

mcoker
mcoker previously approved these changes Jan 22, 2021
Copy link
Contributor

@mcoker mcoker left a 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.

@tlabaj tlabaj dismissed stale reviews from mcoker and jessiehuff via b3b832d January 22, 2021 23:37
mcarrano
mcarrano previously approved these changes Jan 23, 2021
Copy link
Member

@mcarrano mcarrano left a 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!

@kmcfaul
Copy link
Contributor

kmcfaul commented Jan 25, 2021

Looks good, just two interaction questions.

In the Thumb input value example, you can move the slider but the text input doesn't update with the current slider value. The other slider examples do update so I'm not sure if this is intentional.

In the Actions example, you can "lock" the slider but only the text input is disabled, you can still drag the slider and change the value that way. Is the lock meant only for the text input?

@tlabaj
Copy link
Contributor Author

tlabaj commented Jan 25, 2021

@kmcfaul

Looks good, just two interaction questions.

In the Thumb input value example, you can move the slider but the text input doesn't update with the current slider value. The other slider examples do update so I'm not sure if this is intentional.

I see the issue.

In the Actions example, you can "lock" the slider but only the text input is disabled, you can still drag the slider and change the value that way. Is the lock meant only for the text input?
@mcarrano @mcoker there is no styling to disable a slider correct?

@mcarrano
Copy link
Member

In the Actions example, you can "lock" the slider but only the text input is disabled, you can still drag the slider and change the value that way. Is the lock meant only for the text input?
@mcarrano @mcoker there is no styling to disable a slider correct?

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?

@tlabaj
Copy link
Contributor Author

tlabaj commented Jan 25, 2021

In the Actions example, you can "lock" the slider but only the text input is disabled, you can still drag the slider and change the value that way. Is the lock meant only for the text input?
@mcarrano @mcoker there is no styling to disable a slider correct?

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.

@mcarrano
Copy link
Member

@tlabaj @kmcfaul Do you think it's better to leave as is or to remove the example? Again, I see this as a "nice to have" feature that we don't have a hard requirement for right now.

kmcfaul
kmcfaul previously approved these changes Jan 25, 2021
Copy link
Contributor

@kmcfaul kmcfaul left a 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.

Copy link
Contributor

@jessiehuff jessiehuff left a 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:
Screen Shot 2021-01-25 at 1 21 09 PM

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.*/
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

nope. that was removed

@nicolethoen
Copy link
Contributor

we should also open an issue to make the sliders work on mobile.

jessiehuff
jessiehuff previously approved these changes Jan 25, 2021
Copy link
Contributor

@jessiehuff jessiehuff left a 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! 🙂

@tlabaj
Copy link
Contributor Author

tlabaj commented Jan 25, 2021

@nicolethoen there is already an issue open for that. #5363

@kmcfaul kmcfaul merged commit 90df385 into patternfly:master Jan 25, 2021
@patternfly-build
Copy link
Contributor

Your changes have been released in:

Thanks for your contribution! 🎉

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

Successfully merging this pull request may close these issues.

Add Slider component
9 participants