feat: added axis limitation option

[Tormak9970]

Very simple solution that allows users tot limit what axis elements can be dragged on. Addresses #579. I've tested this in an existing project of mine and it seems to work as expected

[isaacHagoel]

Thanks for this. How should it affect keyboard dragging and the accessibility features?

[Tormak9970]

Thanks for this. How should it affect keyboard dragging and the accessibility features?

For keyboard dragging I see to possibilities:

• leave it as is, because its always in one direction because of how the listeners work
• have axis: "x" limit it to left and right arrows, and axis: "y" limit it to up and down

(I think both are equally viable, but it should be noted in the readme depending on which we decide on)

For accessibility, I need to take a look, I didn't think about that, maybe have the axis indicated in the screen reading? I'm not sure if that is necessary though

[isaacHagoel]

If you have a few zones on the screen this feature can make some of them unreachable (e.g axis is set to y and there is another zone to the side). With keyboard you'd still be able to get there.

…

On Thu, Aug 1, 2024, 22:54 Travis Lane ***@***.***> wrote: Thanks for this. How should it affect keyboard dragging and the accessibility features? For keyboard dragging I see to possibilities: - leave it as is, because its always in one direction because of how the listeners work - have axis: "x" limit it to left and right arrows, and axis: "y" limit it to up and down (I think both are equally viable, but it should be noted in the readme depending on which we decide on) For accessibility, I need to take a look, I didn't think about that, maybe have the axis indicated in the screen reading? I'm not sure if that is necessary though — Reply to this email directly, view it on GitHub <#593 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4OZC7632MCVTBQDPH4CPDZPIVXBAVCNFSM6AAAAABLZB5DNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRSHE3DONJQGM> . You are receiving this because you commented.Message ID: ***@***.***>

[Tormak9970]

Hmm, I didn't realize that from looking at it. I think it makes sense to have it prevent vertical/horizontal movement for the keyboard too.

I'll do some testing and update the PR.

[Tormak9970]

@isaacHagoel I believe this should address both issues:

Setting axis to "y" disables dragging via the left and right arrow keys, and alerts the screen reader if the user attempts to use the left and right arrow keys.

Setting the axis to "x" does the same but for the up and down arrow keys.

Both alerts respect the ariaDisabled config property. Any additional thoughts?

[isaacHagoel]

Thanks. I will look into it tomorrow or on Monday. Moving an item between zones is done by starting a drag (enter) and then tabbing around if I remember correctly, not via the left/right arrows

…

On Fri, Aug 2, 2024 at 11:31 PM Travis Lane ***@***.***> wrote: @isaacHagoel <https://github.com/isaacHagoel> I believe this should address both issues: Setting axis to "y" disables dragging via the left and right arrow keys, and alerts the screen reader if the user attempts to use the left and right arrow keys. Setting the axis to "x" does the same but for the up and down arrow keys. Both alerts respect the ariaDisabled config property. Any additional thoughts? — Reply to this email directly, view it on GitHub <#593 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4OZC7YGKVNINMHCHIJC6DZPOCZXAVCNFSM6AAAAABLZB5DNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVGQYTEMJUG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[isaacHagoel]

as you can see in the original code, arrow right is exactly like arrow down, it moves the item from index i to index i+1 if possible, without concerning itself with where the items are placed in space.
To achieve the axis limitation might be tricky.
It can potentially be achieved by checking bounding client rects relative to the original position of the dragged item but i think even that won't work in some edge cases

[Tormak9970]

I see. Perhaps it makes sense to only have the limit work for pointer drag, since its mainly useful for mobile devices

[isaacHagoel]

Let's take a step back for a minute. What is the problem that limiting the drag axis is trying to solve from a UX perspective?

[Tormak9970]

At least for the use cases I've seen, there are often times where you're only using drag and drop for reorderability. Here's the example that led me to make this PR:

I have a music player, and both the queue and playlist views have a reorderable list of songs. I want it to be clear that there's no purpose to dragging other than changing the order, so limiting it to only the y-axis indicates that.

It's also nice on mobile devices in the case where your fingers may move slightly and it keeps the element in line with the list its in

[isaacHagoel]

Just thinking out loud here... If the feature was to only "allow dragging" in a direction that has other items you could displace, would that achieve the same goal? In the image you included the user can still drag upwards and leave the drop zone, with this implementation they will be able to drag up until the items becomes the first in the list and then moving the mouse further up (or to the side) won't take it further up (same way that locking to the axis doesn't let it move to the sides)

[Tormak9970]

Yea that would effectively achieve the same UX. I don't see a use case for one and not the other. Would be more work to implement tho I think

[isaacHagoel]

Yeah it would be harder to implement but would be in line with the lib supporting any special arrangement of items as it does now (e.g. grid, board etc).
If you're keen I am happy to brainstorm, otherwise I can take a crack at it but not sure when I will have time (maybe over the weekend). There will need to be a util that tracks positions of items or something like that

[Tormak9970]

I'm happy to take a crack at it, there may be a relatively straightforward solution by using the indices of the items. I'm also interested in potentially converting the library to TS to make editing/maintenance easier but that would cause major conflicts with open PRs

[isaacHagoel]

I like TS and there were attempts at this in the past but because of all the dom manipulation it always ended up as not adding much safety.

[Tormak9970]

I like TS and there were attempts at this in the past but because of all the dom manipulation it always ended up as not adding much safety.

Thats a solid point. I'll try to get this working, and maybe look into that afterwards. Do you have any thoughts on what the config option should be called. I think something along the lines of singleDropzone or restrictItems would make sense. It also probably makes sense to prevent dropping items from other dropzones onto that dropzone, since they won't be able to be removed. Thoughts?

[Tormak9970]

or perhaps call it dropToOthersDisabled since dropFromOthersDisabled is already an existing option

[isaacHagoel]

We need to spec it out in more detail. I am writing on my phone right now so a bit limited. In my mind it doesn't limit you to a single drop zone but I don't have all the details fleshed out and maybe there will be no choice but to limit it to a drop zone (probably the case).
In general I am thinking the item will calculate a straight line to the next position it could be in (next index if we limit to a single zone) and that would become the 'rail' it would move on (e.g a 45 degrees diagonal line).
Naming is hard, let's decide what the feature is exactly and then name the option :)

[Tormak9970]

That's a good point, probably best to settle on what it will do before naming it.

I feel like it makes the most sense to limit it to a single drop zone (less work to implement, and if we don't do that, then we wouldn't have the benefit of disabling dragging the element out of its drop zone), but I'm open to the idea.

I think we would only need to consider the cardinal directions (so 90 degrees), since as far as I'm aware, elements can only be arranged vertically or horizontally. Did you have something in mind for the 45 degree options?

[isaacHagoel]

A grid

[Tormak9970]

hmm, I was envisioning this being useful for lists, didn't think about a grid. Do you have an example of that? I thought grids were done like the scrabble example in the readme

[isaacHagoel]

Right now the lib makes no assumptions about the layout of dndzones. It is easy to make a grid based example (useful for images or cards). I can make one a bit later

[melMass]

I came to ask about this feature too to make a basic video timeline with multiple tracks, in my case I would like to dynamically "unlock" y based on a dragged threshold (like any editing application)

timelinednd.mov

There is a basic repl of it here: https://svelte.dev/playground/b30dad4700cd49d2afc32b6b0709538e?version=5.2.8

It is easy to make a grid based example (useful for images or cards). I can make one a bit later

Here is a very basic example: https://svelte.dev/playground/bc32f5b9b6134fe790af3508db5e8893?version=5.2.8