Connecting monitor.getClientOffset to a DropTarget does not refresh props

I created a DropTarget and connected getClientOffset as follows:

targetCollect = function (connect, monitor) {
  return {
    connectDropTarget: connect.dropTarget(),
    isOver: monitor.isOver(),
    clientOffset: monitor.getClientOffset()
  }
}

However, when moving drag within the component, the target does not receive updated props with each wiggle of the mouse (only on enter and exit). The target spec’s hover is called however repeatedly. Is there a reason that the clientOffset prop is not injected each time it is changed?

[noah79]

+1. Running into this and wasting a lot of time trying to understand why getClientOffset() works fine in canDrop() - which does get called repeatedly… - but no way to forward to my control ‘where’ over the item we are. I need to be able to insert above and below a treenode, not just “on” it. canDrop() has no way that I can find that lets me actually tell my component which of the many “types” of drops the node has so that my control can redisplay accordingly. Changing the prop in canDrop resulted in an error. Subscribing to onMouseMove doesn’t work during drag and drop operations. This has been a huge waste of time so far…any help would be appreciated.

@ibash, would you mind posting a gist of what you did to solve your problem?

[KnutHelland]

Btw. one other really ugly hack around this issue can be to send in the coordinates as state from dropTarget.hover():

const dropTarget = {
    hover(props, monitor, component) {
        // HACK! Since there is an open bug in react-dnd, making it impossible
        // to get the current client offset through the collect function as the
        // user moves the mouse, we do this awful hack and set the state (!!)
        // on the component from here outside the component.
        component.setState({
            currentDragOffset: monitor.getClientOffset(),
        });
    },
    drop() { /* ... */ },
};

Of course there are tons of more correct ways to do this that would avoid abusing of setState like that. But at least this little hack is very condensed and may do the job until this issue is eventually fixed. It lets you hack around the bug without changing other components and/or files and without relying on library internals.

Edit: this is basically the same as noah79 does, I just didn’t read his code before now.