Figure out the API for nested drop targets

We want to support nested drop target, but make it easy for parent targets to opt out of events when children are active. We have several requirements:

• No use of e argument for e.stopPropagation and the likes. Ideally, we’ll deprecate e and stop passing it in 1.0.
• Children shouldn’t decide whether parents get the events. There may be cases when parent cares about over (e.g. to scroll the view) even if it doesn’t handle drag. For this reason, each drop target should be able to decide on its own whether it wants to react to drop and whether it needs to hover.

We already note nesting in acceptDrop: if isHandled is true, this means some child has already handled drop before us (and parent may decide not to do anything in this case). We need a similar API for enter/over/leave as well as their this.getDropState(type).isHovering counterpart. #85 starts this work by adding a nested dustbin example. We want to find a good API to make it work.

There’s an attempt at adding API for this in #76 but it’s currently too noisy. @itrelease, can you please write down the API you’re proposing there? Or else you can reimplement it on top of #85 so we can see where you’re heading.

This issue supersedes #75.

[AndAShape]

Is there an example of this? What does comparing monitor.isOver() with monitor.isOver({ shallow: true }) mean?

[gaearon]

@deser This is now exposed in 1.0. You can compare monitor.isOver() with monitor.isOver({ shallow: true }) to learn if it’s over the nested target or just the current one.