Auto scrolling

[alexreardon]

Current mitigation: use your trackpack or mouse to scroll while you are dragging. There was actually a lot of work done to make sure scroll is being listened to directly

Currently when dragging with a mouse the window will not automatically scroll. Nor will scroll containers automatically scroll. We could support this behaviour.

A few things to consider:

Scroll containers

• Currently the library does not do too much with the DOM - it just works. Introducing a feature like this might require an additional export: a scrollable container. Perhaps also even an option for Droppables to support auto scrolling. Should it be opt in or default?
• Window auto scrolling would be relatively simpler and could probably be turned on by default.

[kulakowka]

Sounds cool. I've seen this behavior when dragging boards in trello.com. This is very convenient and it seems that this should work by default.

[alexreardon]

Yeah it is very convenient - just need the time to do it!

[tim-soft]

I would personally love this feature, although I'm a little unsure of how I'd integrate auto scrolling into all of my other containers where applicable. DOM magic via CSS selectors?

[alexreardon]

I am super keen to work on this @tim-soft . We are currently working on #2 which is our primary focus for now. Once that ships I am really keen to get onto auto scrolling and touch support #11

We already know all the droppable scroll containers - so i am expecting we can create some interesting scroll propagator for them as well as the window. We will also need to consider keyboard and ensuring that the page / containers scroll as expected with that also

[kupkovski]

Hi guys. Congrats for the excellent work!
Do you have an estimate on how long will it take to be shipped?

[alexreardon]

@kupkovski I try not to give out time estimates - but this is huge priority for us. After we solve the big scale performance we will be on this like bees on honey - sweet glorious honey

[TimNZ]

Sorry everyone, I'm going to look entitled and ungrateful, but auto scrolling is essential and should have been baked into v1.

Love everything about this library otherwise.

This library might be useful for inspiration and implementation time saving.

https://github.com/StreakYC/react-draggable-list

[alexreardon]

We are planning on working on it very soon. We also have a number of competing internal priorities. The plan is to work on it after #86 is shipped.

[jonaskello]

FWIW, react-sortable-hoc has this feature.

[alexreardon]

Yep. It will be added soon

[alexreardon]

I am now starting work on this. If there any great examples people are aware of feel free to post them. I am currently researching!

[joshuacrowley]

https://app.asana.com and https://www.notion.so both have block based DnD, with autoscroll. Both seem to be built with React.

[TimNZ]

I'll state the obvious - Trello :)

[alexreardon]

Assorted thought on behaviour

Mouse / Touch

Window scrolling

Once the user gets close to the edge of the window and the window is able to be scrolled - then we scroll the window.

Droppable scrolling

If the user drags near the edge of a scrollable Droppable we scroll the droppable. If the user goes beyond the edge of the container we continue to scroll at maximum speed. This is unless we are now over the top of a new Droppable - in which case we stop auto scrolling

Priority

If an auto scroll would be activated for both the window and the Droppable at the same time then we give preference to [TO BE DECIDED]

Keyboard scrolling

If ever an item is moved within a list or into a new list and its location is partially invisible then the container or window will be scrolled so that it becomes visible.

Approach

I am still considering where the best place for this logic to live is. Initially I thought a redux middleware (or similar) location would be perfect - but we need to have access to the elements themselves to update their scroll which is not available from the state. Either we split the logic between Draggable and Droppable components which might get hard when it comes to prioritising types of auto scroll, or we put it in a location that has access to both - the dimension marshal. My initial thoughts are that I am not super keen to put it in the marshal as it extends its responsibilities - perhaps too far. 🤔... The challenge is we need a place that has access to the ref's as well as the dimensions in the state. Good times. Nice but bad idea if we put the DOM ref in the dimension state then we can access it from a middleware. This is bad as it breaks the idea of a serialised state..

Without breaking the redux principles the only place right now that has access to the DOM refs and the state is the dimension marshal. Otherwise we need components to also register themselves with another marshal - which feels like a lot of duplication and opportunity for inconsistencies

[alexreardon]

@jaredcrowe and I are white boarding behaviour

[alexreardon]

git checkout -b auto-scroll

😄

[alexreardon]

Still in very early stages of fiddling around. But it is fun to play with!

[alexreardon]

I am wrestling with an issue on mobile safari where a touchmove event provides an incorrect clientX / clientY value after a manually triggered scroll event. The values are then correct on the next touchmove 🙃. Still investigating if it is me or safari

[alexreardon]

I have raised a but in webkit about this one. I can reproduce it in an isolated example. After a scroll a touchmove does not correctly account for clientX, clientY intermittently.

I tried to create a work around for this but I was unable to given that:

• it occurs intermittently
• there can be a few incorrect touchmove events in a row (it could be 0 it could be 3 - or more!).
• i have found no way to know if the touchmove event is accurate or not

Given that the webkit team is responding to the bug I will proceed with the bug exposed in the library. It sucks, but I cannot get around it at the moment. The result of this will be some jittering of a draggable as a window is auto scrolling on iOS11

[alexreardon]

I think #291 is essential for auto scrolling to feel right so auto scrolling will be shipping with #291. Sadly #291 comes with a minor api break so it will push the version to 5.0 😊

[alexreardon]

It may seem a little quiet but this is well underway. There is a lot of complexity in doing this well for all of the different input types

[alexreardon]

Here is our work in progress

• mouse auto scroll for window and droppables
• touch auto scroll for window and droppables
• keyboard in a single list with window and droppable scroll
• keyboard in multiple lists

We have put an extreme amount of love ❤️ into every interaction to make it feel great regardless of your page composition. We have also been giving keyboard lots of attention which is slowing things down a bit. Auto scrolling with a keyboard is a completely different beast to pointer input dragging

[tim-soft]

@alexreardon you're a wizard harry! Is this branch still React v15 compatible?

[alexreardon]

Yep @tim-soft

[alexreardon]

This is the mess I am currently working through:

https://twitter.com/alexandereardon/status/959195944326643713

The browsers update document.documentElement.scrollTop and window.pageYOffset
differently as the window scrolls.

Webkit

documentElement.scrollTop: no update. Stays at 0
window.pageYOffset: updates to whole number

Chrome

documentElement.scrollTop: update with fractional value
window.pageYOffset: update with fractional value

FireFox

documentElement.scrollTop: updates to whole number
window.pageYOffset: updates to whole number

IE11 (same as firefox)

documentElement.scrollTop: updates to whole number
window.pageYOffset: updates to whole number

Edge (same as webkit)

documentElement.scrollTop: no update. Stays at 0
window.pageYOffset: updates to whole number

I have no idea if the rounding is the same between the browsers

[TimNZ]

@alexreardon Sending you a virtual pat on the back, and a cup of tea with a biscuit.

[alexreardon]

I am drinking a tea right now!

☕️

[belief-cyf]

good luck

[Alebron23]

It just so happened that I sent you an email today inquiring about this feature before I found this post. Do you have an ETA when this feature will be ready?

[alexreardon]

We do not give out time estimates. It is actively being worked on so it should not be too much longer 👍

[alexreardon]

This is so close 🔥. There has been some really great work done to ensure this entire experience works in an initiative, beautiful and performant way with mouse, keyboard and touch. Getting keyboard working was a world of pain - but super worth it. It is looking fantastic

Thank you for your patience everyone

[alexreardon]

Branch just went green - getting closer!

[alex6633]

Appreciate your efforts on this !!! 🥇
Need this feature very badly to make my component work.

[Alebron23]

You da man!!

[shruti8789]

Still in very early stages of fiddling around. But it is fun to play with!

@alexreardon
Here, we can see a definite area after which it starts to auto-scroll (both above and down the pane/palette) . Can we customize this area?

[aalian66loop]

any updates on this ;(