-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[Core] MultiSlider component #2536
Conversation
… into review/js/multi-range-slider
Fix lintPreview: documentation | landing | table |
* or between handles for `RangeSlider`. | ||
* @default true | ||
*/ | ||
showTrackFill?: boolean; |
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.
@jscheiny is this prop respected by your impl?
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.
Fix testsPreview: documentation | landing | table |
only one track element, remove some classesPreview: documentation | landing | table |
fix test importPreview: documentation | landing | table |
* write Handle tests for onChange/onRelease movement * Handle maybe calls onChange when released (if different from prop) * rewrite sliderTestUtils: simulateMovement() does it all * enable vertical Handle tests, more utils refactors * refactor Slider & RangeSlider test suites: test handles & track * rewrite MultiSlider tests * tests imports * fix Slider initialValue and displayName
MultiSlider tests (#2576)Preview: documentation | landing | table |
example is broken. will fix shortly |
* maybeRenderAxis => renderLabels * renderFill => renderTracks * border-radius only on track, remove start/end modifiers from segments * fix test utils * add test for handles outside range * fix Label usage in example
MultiSlider refactors (#2569)Preview: documentation | landing | table |
* Slider docs * refactor MultiSliderExample
MultiSlider docs (#2577)Preview: documentation | landing | table |
* utils use ComponentType to support SFCs * drop Slider prefix from Handle types * Handle component extends IHandleProps interface * SliderHandle => MultiSlider.Handle * update tests * fix Handle tests
SliderHandle => MultiSlider.Handle (#2578)Preview: documentation | landing | table |
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.
update on what this PR actually does:
- replace
CoreSlider
withMultiSlider
component that supports arbitrary handles and track segments- 👍
CoreSlider
was internal, so this isn't actually a breaking change
- 👍
- refactor
Slider
andRangeSlider
to composeMultiSlider
internally (instead of extendingCoreSlider
- 👍 APIs unchanged for these two components
- refactor tests by introducing suite for
Handle
and greatly simplifying Slider/RangeSlider suites
value: number; | ||
|
||
/** Whether this handle is non-interactive. */ | ||
disabled?: boolean; |
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 don't think this prop is ever read.
* MultiSlider fixes * Remove disabled prop * Fix typings
MultiSlider fixes (#2588)Preview: documentation | landing | table |
default prop values in docsPreview: documentation | landing | table |
Checklist
Changes proposed in this pull request:
This adds a very general
MultiRangeSlider
component that ultimately should be able to subsume theSlider
andRangeSlider
components.Notes about the component API:
value
- where it gets placed on the slidertype
- specifies how the slider handle should be displayed"full"
- handle appears like it does in aSlider
(default)"lower"
- handle appears like the first slider in aRangeSlider
"upper"
- handle appears like the second slider in aRangeSlider
trackIntent{Above,Below}
specifies the color of the track fill above and below (numerically) of the given handle.Handles are always displayed in ascending numeric order and the values that are returned by
onChange
andonRelease
are always sorted.In addition,
MultiRangeSlider
takes adefaultTrackIntent
prop which is used in the resolution of how to render the color of the track between two given handles. The way that this is resolved is as follows (and is one of my concerns about the API).Important: Note that there is a difference between the
NONE
intent and the absence of an intent entirely (undefined
). The former will render a gray track between the two handles and the latter will fall-through to the next color in the hierarchy above.I previously allowed the specification of colors instead of intents but that didn't seem very blueprint-y.
Reviewers should focus on:
I have explicitly not written tests/docs for this yet, as I would first like to iterate on the API as I'm not convinced what I've written is particularly nice (worked for our use case but don't know if it generalizes well). Once we've iterated and nailed down an API I will gladly write tests and docs for this component.
I've written some questions in the code, but one additional question I have is should this component live in
labs
first to incubate before moving intocore
?Not addressed in this PR (requires follow-up):
To keep this PR simple(r) and easy(er) to review, I have not made many changes to the existing slider components but in 1-2 follow up PRs I would like to:
Slider
andRangeSlider
to be simple wrappers aroundMultiRangeSlider
CoreSlider
and refactor intoMultiRangeSlider
The second one is questionable, especially if there are plans to add a slider that does not fit into the multi range slider model.
Screenshots
Two tailed slider:
Disabled:
One tailed:
Weird:
Vertical:
In action: