Allow disabling drag or drop on a single gridlist item

[GermanJablo]

Provide a general summary of the feature here

As the title says, allow disabling drag or drop on a single gridlist item.

I saw the disabledBehavior property, but if I disable drag for an item I also disable selection, and I don't want that.

Another idea I had is to filter it out the item to deactivate in the getItems function that I pass to useDragAndDrop. With this, although I get the dragEvent to have no content or data to drag, I can still drag the item. In other words, data-drop-target, react-aria-DropIndicator and renderDragPreview still appear.

I know that in renderDragPreview I could return an empty div for example, but the mouse would still show that something is being dragged, and the drop-target/indicator still activates.

🤔 Expected Behavior?

Allow disabling drag or drop on a single gridlist item

😯 Current Behavior

It is not possible to disable drag or drop on a single gridlist item

💁 Possible Solution

No response

🔦 Context

a little context about my use case, because I think it may be helpful.

I'm trying to fake a Tree with a gridlist (turning the nesting level into an indent).

The Home element has some peculiarities:

❌ I don't want it to be draggable. ❌ I don't want to be able to drop "before" or "after" it (onReorder). ✅ I want it to be able to drop "inside" it (onItemDrop).

Note: this issue come from this discussion: https://github.com/adobe/react-spectrum/discussions/5697#discussioncomment-8146985

💻 Examples

No response

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[LFDanLu]

Discussion in a PR with some relevant points: https://github.com/adobe/react-spectrum/pull/5641#discussion_r1458044171. In short the team is a bit concerned about possible confusion if a item can be selectable but not draggable, especially if said item is in a larger set of selected items which are draggable. That being said, I can definitely see how being able to drag "Home" in your example might be confusing for the opposite reason to a user, especially if it wouldn't actually result in any information being conveyed/transferred on drop. Perhaps there is a middle ground where we allow drag to be disabled for a non-selectable item?

[GermanJablo]

possible confusion if a item can be selectable but not draggable, especially if said item is in a larger set of selected items which are draggable

Good point. Some solutions I can think of:

1. If the selection contains at least one non-dragable item, disable drag operation.
2. Provide a callback that returns a boolean and allows each user to implement their drag operation enabling logic. EDIT: I just realized that useDragAndDrop has a shouldAcceptItemDrop* method. What I'm saying would be something similar but to drag operation: shouldAcceptDrag or something like that.

*target.dropPosition inside that method always gives me "on" even when it should be "before" or "after". Is that a bug?

[LFDanLu]

Chatted with the team, at the moment we feel that the least confusing option would be always allowing drag operations if the selected items contain both draggable and non-draggable items and then filtering/erroring/providing some kind of information of what items weren't draggable when the drop happens. For the case where there is only a single item selected/dragged, we could potentially prevent dragging from happening if said item isn't draggable. Still need to hash out the details of what code changes would need to happen to enable this but thats a high level view.

I think your second solution could be interesting, would need dig around and investigate how exactly that would play with the internals in the dnd code.

target.dropPosition inside that method always gives me "on" even when it should be "before" or "after". Is that a bug?

That sounds like a bug, it should be checking before and after as well to differentiate between reorders operations and on item drop operations.

[GermanJablo]

Thanks for the response @LFDanLu. The behavior you mention in the first paragraph seems very confusing/strange to me, and unnecessarily complex.

IMHO All of that is resolved with what you mention in the second paragraph (i.e., my second proposal). That API would give each programmer the freedom to enable or disable drag however they wanted, and is also consistent with the existing shouldAcceptItemDrop API.

That sounds like a bug, it should be checking before and after as well to differentiate between reorders operations and on item drop operations.

Yep, that's what I thought