Welcome to the React feedback portal. We’re happy you’re here! If you have feedback on how to improve the React, we’d love to hear it!

  • Check out the features or bugs others have reported and vote on your favorites. Feedback will be prioritized based on popularity.
  • If you have feedback that’s not listed yet, submit your own.

Thanks for joining our community and helping improve Syncfusion products!

1
Vote

Hi,

I'm using the Tailwind theme and I found that on the Treeview control when I'm using drag/drop to reorder some siblings that occasionally when I drop in a position where the between-node indicator line is showing (e-sibling) and the drag icon is showing the icon to indicate dropping would re-order the re-order wouldn't actually happen (i.e. the dragged node would revert to its pre-drag position).

What seems to be happening in this case is that in the nodeDragStop event the droppedNode argument is empty and the target is the indicator line (with class e-sibling). This didn't seem to happen under the default material theme for the demos, so I think it's likely something to do with the way the indicator line is styled /positioned under tailwind is meaning it can end up being the target of the drop event where it can't in the material theme.

I modified the drag/drop demo to log to the console when the droppedNode argument is empty - I found that to trigger the bug most reliably if I drag a node up and down a bit on the position roughly between the nodes such that the tip of the browser pointer is just about over the blue indicator line and then do the drop then it seems to have the issue of droppedNode being blank. This is a screenshot I took of such a position - unfortunately the screenshot doesn't show the mouse pointer, but the tip of it was just about over the blue line  - then when I released my mouse pointer after taking the screenshot the console log showed "no dropped node":

dropfailedexample.png

Now it's possible that dropping on the indicator line actually should still work and that droppedNode should be set - from looking at the code for the underlying Javascript Treeview I've noticed that in the dragAction method and dragStop callback (on dragObj) that the this.removeVirtualEle() calls (to remove the indicator) get called fairly early on in those functions which means that if e.target is the indicator line rather than a node's list item then when they later e.g. find the drop element by calling closest(e.target, '.' + LISTITEM) or drop root by calling closest(dropTarget, '.' DROPPABLE) will get nothing back because e.target has been removed from the DOM by that point so has no parent so closest won't find anything.