minop1205 / react-dnd-treeview

Line 73 in bae03af

if (sourceNode === undefined || sourceNode.parent === targetId) {

Hi,

I understand why this has been implemented in this way, however, it would be great if there were a way to disable this behaviour. I can't share the true reason why I'm flagging up this behaviour as it's todo with a trade secret of my company. However, this could be useful to people for a variety of reasons e.g. If you'd like to display an warning/error (or play a sound) to the user when they try to carry out this action.

Current Behaviour
Dropping a child node onto it's parent does not result in the onDrop callback being called.

Desired Behaviour
Dropping a child node onto it's parent results in the onDrop callback being called.

Many thanks,

Ben

I've started work on a PR for this by the way - I think we can do this in a way which preserves the current behaviour unless the user specified an alternative behaviour 👍

@bcheidemann
Thank you!

Using the current behavior as a default, how about adding the following API to allow dropping between siblings (or self node)?

<Tree
  {... .props}
  acceptDropToSiblings={true} // default is false
  )}
/>

@minop1205
This one one way I thought to implement it and I would be happy to do it like this.

Alternatively, we could do something like this:

<Tree shouldDrop={(...args) => boolean} ... />

Default would be existing behaviour.

This would be more flexible but may be overkill.

Let me know which option you prefer! :)

Passing the shouldDrop callback as you suggested is more flexible, so let's implement it this way.
But It's a very powerful extension, but depending on how you use it, it could potentially break the tree.

For example, dropping from parent to child as shown in the figure below may cause inconsistencies in the tree, but I think that is the user's own responsibility.

The property name could be shouldDrop, or it could be something like canDrop. Also, I think it is sufficient to include source and target in the args, but you can include anything else if you want.

I would like this property to default to undefined, and if undefined, to do the current behavior.

Yeah I agree - presumably if the user is defining behaviour like this they know what they're doing. But none the less, I will include a warning in the docs 👍 I like canDrop - that's seems quite intuitive to me.

@bcheidemann I just released this feature as v1.3.0.
I have made some commits for the release. Please check this PR for details.
#27

Thank you very much!

No problem at all, thanks for publishing it! :)

Drop events do not register when sourceNode.parent === targetId