-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Maintain scroll position post-drop #291
Comments
Duplicate: #290 |
I can confirm that the scroll is shifted by the size of the dropped item. I am currently attempting to create a reproducible example and then i'll explore ways of getting around it |
I have set up a little independent demo that has a list with changing items. Unable to replicate issue. I have been digging into React internals to see if it is doing some scroll magic |
It turns out the issue is only occurring in Chrome. This got me thinking that it is probably not react. It turns out the issue is caused by Chrome trying to be clever with Scroll Anchoring. To get around this permanently we will add this style (probably to a droppable) overflow-anchor: none; |
As a work around you can add the style for yourself in the meantime |
Unfortunately to add this it will be a breaking change as we need to add a property to droppables 💥. I will add a |
Closed by #321 |
FYI, for anyone coming here looking for answers. I have done something that doesn't look super great, it scrolls after that state is saved and scrolled to the top. And it is very hacky, but it does work to get the dropped item into focus at the top of the scroll container.
Edit: After doing some more research (aka googling), I have discovered a much simpler cleaner way to do this. Albeit still fairly hacky.
Then toward the bottom right after saving the state, I do this:
So it is better, although, you can still see it go to the top, then go back to the original scroll position again. Very hacky, but it works! |
@mdodge-ecgrow |
When dropping an item it is up to a consumer to update their state syncronously. However, this change can result in a shift in the scroll of the container / viewport that the user is interacting with. Ideally there would be no shift after a drop.
I have avoiding this until we do #27. That feature makes this very obvious. I have been hesitant to do this until now as it involves doing some post-drop work (potentially correcting scroll's) which we are not doing at this point. However, I think it is time.
The text was updated successfully, but these errors were encountered: