clauderic / clauderic/react-sortable-hoc
Don't use getScrollingParent if getContainer is a prop
- Dominant language
- JavaScript
- Stars
- 10.9k
- Forks
- 959
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
I've combined `react-sortable-hoc` with [simplebar-react](https://github.com/Grsmto/simplebar/tree/master/packages/simplebar-react). That was no big deal except one side effect: The autoscroll didn't worked anymore. So I've added `getContainer` to the props and returned the _correct_ element but it still didn't worked.
After investigating around I've found the solution: `getScrollingParent` was the bad guy. It bubbled to the completely wrong element because the element returned in `getContainer` has no `overflow` css property. But in my case it doesn't matter.
Now I've added this to the element, but I would suggest that if somebody provide a scroll container via `getContainer` the programmer knows what he/she is doing. My idea is to bypass `getScrollingParent` if `getContainer` exists.
BTW: `getScrollingParent` could return wrong elements, in example if the element has `overflow-x: auto;` but the sortable axis is `y`.
Contributor guide
No contributing guide indexed for this repository
Research direction
Trace the getContainer and getScrollingParent entry points, then follow how the selected element is used by autoscroll. Confirm the behavior with a supplied container and with an axis whose overflow does not match; done means getContainer takes precedence and the reported axis-specific case is handled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, react
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100