Components: Abstract a base class out of drop-list that could be used to create other common drop-zones

[nayfin]

Bug, feature request, or proposal:

feature request

What is the expected behavior?

A base drop-zone directive with all the plumbing of the drop-list directive but without the automatic ui behavior. This base directive would be used to extend to the current drop-list directive and used as a base class to create other common use-case directives.

What is the current behavior?

The current drop-list directive comes with a lot of great built-in features, but sometimes I don't want the ui to sort automatically, or pull from my origin drop list. We need a base class with all the rigging of the drop-list without all the automatic UI.

What are the steps to reproduce?

Here's an example of the ui automatically pulling drag item from the origin list on entering the drop-list. Even though we want to copy the item, not have it deleted from the origin list. This happens automatically and I cannot find a simple way of turning behavior off.

https://stackblitz.com/edit/angular-cdkdrag-across-templates

What is the use-case or motivation for changing an existing behavior?

This gives people who wish to contribute new drop-zone ideas a clean place to start, helping to ensure future code is on par with current standard and enabling new ideas. It also would give end-developers a good starting point for their more custom drop-zones.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

all

Is there anything else we should know?

I am a huge fan of the new drag drop features and want to see them flourish. I would like to be able to make this change, but I would likely need significant input from the author @crisbeto

[nayfin]

I started the initial steps to this and there looks like there will be quite a bit to change. I don't think abstracting a base directive will be too difficult, but there are a lot of corresponding interfaces and classes that will likely need to have the same treatment to match the changes e.g.
CdkDropListContainer will need to extend a CdkDropZoneContainer base, so that the base can be imported by a CdkDropZone and vice-versa.

Also, avoiding braking changes could increase complexity.

[crisbeto]

We're already in the process of doing this, and yes the tricky part is keeping backwards compatibility without duplicating a ton of code. It also probably won't be a base class, but something you attach via a service to an arbitrary DOM node.

[nayfin]

That's great news, thanks for all the awesome features. Is there any way I can peak that branch? I don't see it in the github branches, and I'd love to see how it's being developed. Also, drop coordinates, relative to the drop zone, would be super useful on the drop event emitted by the drop zone.

[jkainth]

@crisbeto any rough idea when this is close to completion.

I'm in the same boat where i don't want to use the drop-list but create my own container.
But the drag-ref is so tightly coupled with the dropListRef. Ideally the moving items, into and out of container etc should not be anything the drag-ref should concern itself with.

That way we can have a very generic drag-ref that knows how to drag, gen previews, placeholders etc only and the containers(refs) should do what they need to.

[nayfin]

@crisbeto I've been looking through the recent changes, and if I'm not mistaken it looks everything is there to close this issue. I'm looking at how CdkDropList uses the DropListRef, and I am hoping I can do something similar to create a CdkDropCanvas, a drop zone that drops the items in place instead appending to a list. Does this seem feasible to you based on the current state of the API or do you have more changes in mind that will further facilitate this kind of work? If it's ready and stable, I can document creating the custom dropzone and add instructions to the feature readme. Thanks!

[joschne]

I'd also need this requested feature.

@crisbeto, what is the current state of the development? Do you have any rough idea about when this will be ready?

@nayfin, what did you do meanwhile to cover the need some kind of DropCanvas?

[crisbeto]

It's not an abstract class, but there is a service that allows for drag&drop functionality to be attached to DOM nodes: https://github.com/angular/material2/blob/master/src/cdk/drag-drop/drag-drop.ts#L26

[nayfin]

@crisbeto I appreciate all the work that went into this, and I'm a big fan of the API. My hope was to have some way of hooking into the drag drop events and maybe being able to optionally trigger some of the default drag-drop behavior. I see that the drag-drop logic was abstracted out of the directives and into drag and drop-list refs and that the corresponding directives use the drag-drop service to attach the ref logic to the component. However, I can't figure out how to attach these refs without pulling in all of the default drag and drop-list behaviour. I tried removing the subscriptions to some of the drop-list events in the drop-list directive but the the drop-list ref events still fired and the drag behavior did not change. If I am missing something, would you be able to post some basic example around how to use these refs to accomplish the desired behavior? I'd be happy to add it to the docs. I think this will be a very important thing to have available in the library, as it will greatly simplify building future features like resizable and drop-canvas directives.

[nayfin]

@joschne I have been waiting on resolution to this issue before implementing a drop-canvas. In its current implementation I believe I would have to rewrite a lot of the event logic, and bloat some of the services with a lot of conditional logic. I believe the solution would be to move the drag logic back onto the directives, and have the refs simply emit the drag/drop events to the consuming directives. I realize that this is probably not ideal, as @crisbeto just spent significant effort moving the behavior logic out of the directives. I can take this work on, I would just like thumbs up/ thumbs down on if this is an acceptable path before starting. Again, I could also just be missing something and everything is already in place, if it is I can't figure out how to use it for the ends we have in mind.

[nayfin]

@crisbeto I'm going to move forward with the work I described: pulling behavior logic out of drag and drop-list refs and moving it to the directive, the refs will just be responsible for emitting the drag events and the directives will handle all behavior, any behavior that would be useful for multiple directives I plan on moving into either drag-utils (pure functions) or the drag-drop service (require shared state).

I'm planning on keeping anything that would be useful for multiple directives on the ref (e.g. dragStartDelay, disabled, data). I'm struggling to figure out where to put things like preview/placeholder logic, for the moment I'm leaning towards leaving them on the ref as well, but that could change as I dig in.

I see this abstraction being useful for facilitating implementation of a CdkResize directive (the same drag events can be used to inform behavior), so I will be making most of my design decisions with that feature in mind.

Please let me know if I am way off base here. I'm no slouch but this will take me significant effort and time, both of which I'd like to direct at other things if the core team has other plans for this feature. My plan is to submit a PR once I have a decent proof of concept in place. I'll backfill tests once I get a thumbs up on the direction of the change. Thank