react-dnd / dnd-core

Drag and drop sans the GUI [Legacy Repo]

React DnD

Drag and Drop for React.

See the docs, tutorials and examples on the website:

http://react-dnd.github.io/react-dnd/

See the changelog on the Releases page:

https://github.com/react-dnd/react-dnd/releases

Questions? Find us on the Reactiflux Discord Server (#need-help)

https://www.reactiflux.com/

Shoutouts 🙏

Big thanks to BrowserStack for letting the maintainers use their service to debug browser issues.

dnd-core's Issues

DragDropMonitor failes to notify subscribeToStateChange subscribers in some cases

Currently dnd-core takes for granted that it store.subscribe() will notify all state changes. But redux does not guarantee that, e.g. when an earlier subscription dispatches a new action to the store.

The consequence is that render() will not always be called when needed.

Drop action nulls dragOffsets

Based on the tests this is expected behavior, but I'm not sure it should be.

For example, a listener that renders the drag might rely on monitor.isDragging() and monitor.getSourceClientOffset(), as you demonstrate in examples for react-dnd's DragLayer.

Use eslint-config-airbnb

TODO

• Implement/test dropping on target (drop on drop target, endDrag(true) on drag source)
• Implement/test dropping somewhere else (endDrag(false) on drag source)
• Think: should we let drop return a value and pass it to endDrag instead of a boolean? SOLVED: yep we do that now.
• Implement/test subscription to state (let DragDropContext expose addChangeListener/removeChangeListener that proxies to DragOperationStore?), we'll use that in React for letting components update their state
• Think: consumer may want to “recalculate” drag state at some point. Imagine canDrop (we haven't talked about it yet, but it should be implemented at some point) that depends on props, and props changed. Can React part tell dnd-core that it needs to “reconsider” some stuff it may have calculated concerning a drop zone or drag source? — SOLVED: it is up to consumer to test canDrop via this.context.canDrop(targetHandle) at any time they find it convenient. dnd-core will throw if the condition is not met when calling drop.
• MY FAVORITE PART (closely related to previous point). You have a list of React components in an array *but without keys. The items reorder. How to make sure their drag states still match? This might be canJoinDrag or some other API that makes more sense. TEST IT.* SOLVED: added isDragging(context) to drag source API.
• Think: how do we go about event bubbling?
• Figure out how we represent “entered” drop targets (gotta store a list in manager to support nesting, DragDropContext will ask the manager to implement isOver(descriptor), isInside(descriptor)). Implement and test.
• Finally, the boring part: tracking drag coordinates.

Update to Babel 6

In Dnd-Core,HandlerRegistry is imported but not used in DragDropManager.js

Tests involving Symbols currently failing

After cloning and npm install && npm test:
1) DragDropManager handler registration accepts symbol types: Error: expected fn not to throw an exception

2) DragDropMonitor state tracking treats symbol types just like string types: Error: Invariant Violation: Type can only be a string or a symbol.

Be resilient against errors in hooks

It would be nice to be more resilient to errors inside user code (drag sources and drop targets). If user code throws, we will rethrow but it's important we have finally blocks that at least ensure consistent state.

Idea: Integrate With External Redux Store

An idea I had - feel free to close if this is unlikely to make the roadmap.

When using ReactDnD in a Redux app, it would be nice if the drag/drop state were stored in the primary app store and updated via Redux actions. Currently dnd-core stores the drag/drop state in its own internal store.

This change would let you automatically debug drag/drop state via Redux Dev tools.

I imagined this could accomplished using the same approach that https://github.com/rackt/react-router-redux adopts: by providing a reducer and middleware and firing actions at the main application store.

TypeError: (0 , _dndCore2.default) is not a function

import DragDropManager from 'dnd-core'
import createTestBackend  from 'dnd-core'

 let manager;
  let backend;
  let registry;

  beforeEach(() => {
    manager = DragDropManager(createTestBackend);
    backend = manager.getBackend();
    registry = manager.getRegistry();
  });

get error

TypeError: (0 , _dndCore2.default) is not a function

Manual dispatch in DragDropActions#drop()

I noticed you're manually calling the dispatcher in DragDropActions#drop(). https://github.com/gaearon/dnd-core/blob/master/modules/actions/DragDropActions.js#L90

Couldn't you instead dispatch all the dropResults at once? Or, if you need to do each one at a time, call a separate action instead of the raw dispatch method?

So instead of this

targetHandles.forEach((targetHandle, index) => {
  ...
  this.dispatch(dropActionId, { dropResult });
});

you could do this

const dropResults = targetHandles.map((targetHandle, index) => {
  ...
  return { dropResult };
});

return { dropResults };

or this

targetHandles.forEach((targetHandle, index) => {
 ...
 this.dropSingle(dropResult);
});

// elsewhere in DragDropActions class
dropSingle(dropResult) {
  return { dropResult };
}

If neither of these are options, I'd be curious to know why so I can address in Flummox.

`isOver` and `DropTarget` `hover` race condition

I ran into an interesting bug today while I was writing some tests for a hover handler. The relevant code is here.

During a drag operation, for any drop target that the drag operation goes through, for the first frame of that hover incident, isOver will incorrectly return false in the hover handler. This is because that handler is called before the drop target is registered as being hovered over in the monitor's store.

I have a hover handler that looks like this:

  hover(props, monitor, _component) {
    if (!monitor.isOver({ shallow: true })) {
      return undefined;
    }

    do_the_thing();
  }

In normal use this probably doesn't matter, as you'd be hovering for more than one frame. In tests, however, it's easy to trigger. With the following test code, the do_the_thing() part never happens.

    backend.simulateBeginDrag([ dragSources.get(0).getHandlerId() ]);
    backend.simulateHover([ dropTargets.get(1).getHandlerId() ], { clientOffset: { x: 50, y: 35 } });
    backend.simulateDrop();
    backend.simulateEndDrag();

What I've done for now to work around this is call simulateHover twice. What this does is triggers two calls to hover - one where the drop target is not yet registered, and one where it is.

    backend.simulateBeginDrag([ dragSources.get(0).getHandlerId() ]);
    backend.simulateHover([ dropTargets.get(1).getHandlerId() ]);
    backend.simulateHover([ dropTargets.get(1).getHandlerId() ], { clientOffset: { x: 50, y: 35 } });
    backend.simulateDrop();
    backend.simulateEndDrag();

What a fun bug!

Flummox's Actions.js grabs all console logs

Hi, I created this issue with the flummox library: acdlite/flummox#264.

My problem is that under chrome browser all my logs/errors/warnings are shown to be logged from Actions.js. This is very frustrating because now I don't see the filename/line number where error is.

I see that in flummox's master branch the file is removed. Can you please check if it would be possible to bump up the flummox version or replace it with redux (as suggested on flummox's page). Or let me know if you know any workaround. Following is a screenshot from my browser:

Thanks
chetan.

endDrop notification.

DropTarget component can get drag object enter or leave state by isOver changes through componentWillReceiveProps method. I want to know any simple way to tell targets the drag is end.

I see dragSource has endDrop callback. it's possible implement in dropTarget?

Expose higher-level Observable API

We want to expose an API consumable by React 0.14 with the new observe hook for sideways data loading.

The observable we expose from DnD Core will register a drag source (or drop target) on subscribe, unregister it on unsubscribe and, given (context, backend) => data, return a stream of data that gets pushed on every context change event.

We will also probably try to separately build a higher-order component to polyfill observe until React 0.14 ships with it.

How do we implement dragOver and coordinate tracking?

In React DnD, we have an API to hook into continuously updating drag offset as you move the dragged item. There's a separate DragOffsetStore which is currently only used by DragLayerMixin. It is essential to separate tracking coordinates from the rest of state tracking, because only componenents interested in coordinates should subscribe to it. These events just fire way too often so subscribing everyone to them is not an option. And usually drag layer is the only thing that cares about the coordinates. Finally, in React DnD, there is also an over drop target hook that gets called continuously during drag. It complements enter and leave.

It is not yet clear to me how to translate these concepts to dnd-core.
Here are my initial thoughts:

• We will not implement enter and leave on drop targets. This is already solveable by using addChangeListener and checking isOver(targetHandle, shallow) with first class support for nested drop targets using second parameter. So this is out of equation already.
• We need over in drop target API. Its main use case is performing side effects continuously in response to user moving the mouse while dragging. For example, parent drop target may scroll window when you're dragging something too close to window bottom or top. I would like to rename it to dragOver so it's consistent with other methods that have a verb in their names. It would be called on all entered drop targets for which isOver() returns true. It would be up to drop zones to inquire about isOver(handle, shallow) if they only care about shallow drag over.
• We don't want to fire change events on drag action for performance reasons. The only thing that may have changed is the coordinate, and we want to have a separate subscription mechanism for that. Now that I speak of this, I think coordinate tracking may be out of scope of this project altogether. If it aims to be backend-independent, there are cases where coordinates make zero or not as much sense (tests, multi-touch screens, etc). Sure, the backend should be able to call this.actions.dragOver so drop targets receive it, but I don't think it needs to pass any coordinates. Maybe the best option is to be ignorant about the additional data backend passes to beginDrag and dragOver without strictly calling it coordinates. Just expose getInitialDragData, getLastDragData on context and, instead of a single change event, expose change and drag events. It is up to consuming library to interpret that data.