[CdkDrag]: Allow out of scope binding with drop container
See original GitHub issueBug, feature request, or proposal: proposal
What is the expected behavior?
CdkDrag
accepts CdkDropListContainer
as an @Input
(in addition to the current injection logic)
What is the current behavior?
CdkDrag
accepts CdkDropListContainer
from DI (optional) or through direct assignment.
What is the use-case or motivation for changing an existing behavior?
When CdkDropListContainer
comes from DI it requires the drop container to be a direct parent of the drag element.
When working with dynamic content (table, tree, select, or any “portal like” components) it is sometimes not possible to have the container and the drag element in a parent/descendant relationship.
For example: In a CdkTable
dragging a header cell left/right having the header row as the drop container. The row and cell are not defined as parent/descendant in the template and the view creators will not pass the proper injectables in such case.
The current implementation does not require a drop container, it’s optional. So adding an @Input
is quite simple. The init only happen when actual dragging starts so it shouldn’t be an issue.
The CdkDropList
will require some modifications because it uses a template query to get all of the child drag items it manages. This is also doable… Maybe by having a flag that defines the work mode or another directive that does not use a template query.
When a drag item is assigned a drop container it will notify the container so it can store a ref to it… doing the same when the drag is destroyed or disconnected from the parent drop container.
Thanks!
Issue Analytics
- State:
- Created 5 years ago
- Reactions:7
- Comments:13 (10 by maintainers)
@NitsanBaleli I create demo.
Thank you for submitting your feature request! Looks like during the polling process it didn’t collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular’s scope, we’d encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.