Improve Slider Scrolling #8321
Improve Slider Scrolling #8321
Conversation
📝 WalkthroughWalkthroughThe pull request introduces improvements to the Changes
Assessment against linked issues
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
| if (sliderElement) { | ||
| sliderElement.addEventListener("wheel", handleWheelEvent, { passive: false }); | ||
| } | ||
| }, [handleWheelEvent]); |
There was a problem hiding this comment.
I was a little surprised about this solution.
In my view the dependency that makes sense would be sliderRef.current. I read that components are not rerendered if refs change, which makes sense because the concepts behind refs is to reference objects that are not needed for rendering (according to react.dev. I thought that hooks would still be updated, but this must be the wrong assumption.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
frontend/javascripts/components/slider.tsx (1)
50-71: Consider simplifying the wheel event handler conditions.The wheel event handler implementation is correct but could be more maintainable.
Consider this refactoring to improve readability:
const handleWheelEvent = useCallback( (event: { preventDefault: () => void; deltaY: number }) => { - // differentiate between single value and range slider - if (onWheelDisabled || value == null || min == null || max == null || !isFocused.current) - return _.noop; + if (onWheelDisabled || !isFocused.current || value == null || min == null || max == null) { + return; + } + + event.preventDefault(); + const diff = getWheelStepFromEvent(ensuredStep, event.deltaY, wheelStep); + if (range === false || range == null) { - event.preventDefault(); - const newValue = value - getWheelStepFromEvent(ensuredStep, event.deltaY, wheelStep); + const newValue = value - diff; const clampedNewValue = clamp(min, newValue, max); if (onChange != null) onChange(clampedNewValue); } else if (range === true || typeof range === "object") { - event.preventDefault(); - const diff = getWheelStepFromEvent(ensuredStep, event.deltaY, wheelStep); const newLowerValue = Math.round(value[0] + diff); const newUpperValue = Math.round(value[1] - diff); const clampedNewLowerValue = clamp(min, newLowerValue, Math.min(newUpperValue, max)); const clampedNewUpperValue = clamp(newLowerValue, newUpperValue, max); if (onChange != null) onChange([clampedNewLowerValue, clampedNewUpperValue]); } }, [value, min, max, onChange, range, onWheelDisabled], );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
frontend/javascripts/components/slider.tsx(4 hunks)frontend/javascripts/oxalis/view/components/setting_input_views.tsx(2 hunks)
🔇 Additional comments (4)
frontend/javascripts/components/slider.tsx (3)
5-5: LGTM! Clean prop and import additions.The new optional callback prop and React hooks imports are appropriate for implementing the reset and focus-based scrolling functionality.
Also applies to: 13-13
47-48: LGTM! Proper focus management implementation.Using useRef for focus tracking is the correct approach as it persists across renders without causing re-renders.
87-106: LGTM! Well-implemented reset functionality.The double-click handler correctly implements the reset-to-default functionality with proper type handling. The focus/blur handlers and touchAction style are appropriate additions.
frontend/javascripts/oxalis/view/components/setting_input_views.tsx (1)
197-200: LGTM! Clean implementation of reset functionality.The resetToDefaultValue method is properly implemented with null checks, and the onResetToDefault prop is correctly connected to the Slider component.
Also applies to: 218-218
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
CHANGELOG.unreleased.md (1)
16-16: Consider more concise wording.The phrase "In order to" can be shortened for better readability.
-- Improved the scrolling behaviour of sliders: In order to scroll them, sliders need to be focused. It is also prevented that the parent element is scrolled together with the slider itself. [#8321](https://github.com/scalableminds/webknossos/pull/8321) ++ Improved the scrolling behaviour of sliders: Sliders must be focused to scroll them. Additionally, parent element scrolling is prevented when using the slider. [#8321](https://github.com/scalableminds/webknossos/pull/8321)🧰 Tools
🪛 LanguageTool
[style] ~16-~16: Consider a shorter alternative to avoid wordiness.
Context: ...ved the scrolling behaviour of sliders: In order to scroll them, sliders need to be focused...(IN_ORDER_TO_PREMIUM)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
CHANGELOG.unreleased.md(1 hunks)frontend/javascripts/components/slider.tsx(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/javascripts/components/slider.tsx
🧰 Additional context used
🪛 LanguageTool
CHANGELOG.unreleased.md
[style] ~16-~16: Consider a shorter alternative to avoid wordiness.
Context: ...ved the scrolling behaviour of sliders: In order to scroll them, sliders need to be focused...
(IN_ORDER_TO_PREMIUM)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: circleci_build
🔇 Additional comments (1)
CHANGELOG.unreleased.md (1)
16-16: LGTM! The changelog entry is well-structured.The entry correctly documents the slider improvements, follows the changelog format, and includes the appropriate PR reference.
🧰 Tools
🪛 LanguageTool
[style] ~16-~16: Consider a shorter alternative to avoid wordiness.
Context: ...ved the scrolling behaviour of sliders: In order to scroll them, sliders need to be focused...(IN_ORDER_TO_PREMIUM)
There was a problem hiding this comment.
cool! the code looks good and testing went smoothly mostly, too. I noticed two things, though:
-
double clicking the opacity slider for a segmentation layer, resets the value to 100. however, the default value is 20 for segmentation layers. can you have a look whether it's easy to fix this?
-
I already noticed this on master and maybe it's unrelated to the new slider wrapper, but could you please doublecheck this: when dragging the slider and moving on the y axis, text in the UI is selected. this is not critical, but maybe related to the following problem: sometimes the cursor changes into a "grab" pointer and the slider knob does not move anymore. if I release the mouse button, the knob is still moved when I move the mouse. i have to click again to get rid of it. can you try to reproduce this and afterwards temporarily remove the custom slider component and test whether the problem still exists? I can provoke this by clicking and holding for a moment and only then start to move my mouse.
https://github.com/user-attachments/assets/036f8861-6083-4a46-863e-c9981903e7d9
https://github.com/user-attachments/assets/4da1f440-1b60-4da7-9edd-b7ae339fddf1
by the way, the one moment where the slider jumps to 255, I did a doubleclick, so this is fine :)
|
|
||
| const handleWheelEvent = useCallback( | ||
| (event: { preventDefault: () => void; deltaY: number }) => { | ||
| // differentiate between single value and range slider |
There was a problem hiding this comment.
the comment should probably moved to the other if.
| const handleWheelEvent = useCallback( | ||
| (event: { preventDefault: () => void; deltaY: number }) => { | ||
| // differentiate between single value and range slider | ||
| if (onWheelDisabled || value == null || min == null || max == null || !isFocused.current) |
There was a problem hiding this comment.
you could add || onChange == null and then remove the onChange-ifs below.
URL of deployed dev instance (used for testing):
Steps to test:
(- you can also test this with double clicking the slider for the brush size in the tool bar (having the brush tool active): it should be reset to 50)
TODOs:
Issues:
(Please delete unneeded items, merge only when none are left open)