CdkDragDrop - Issues with dynamic height on CdkDropList

[jingfee]

I'm using CdkDragDrop to make a dynamic grid which can be restructured with drag and drop from the user. I created this StackBlitz to illustrate both my use case and the issue I'm facing https://stackblitz.com/edit/angular-rvv4g9.

When I have two elements on the same row I would like to drop one of the elements on an empty row to separate them and create a new row. To do this I inserted empty rows inbetween all rows, when you drag an item they are illustrated with a red background. Since the elements I'm dragging have a rather large height I would like the empty rows to start out small, and when inserting items into them, make them expand.

The issue I'm facing is if you drag for example the element "1" over the row between it and the "3", you can see the row expand, then continue to drag the "1" down below the "3", and you cannot drop the item there.

I think the "drop-area" is not recalculated, and is being blocked by another element which has expanded.

[matthewerwin]

The drop area is cached in v9. There are a lot of issues with correct drop-area clientrect detection. In dynamic cases like this but also even in rudimentary static cases such as: #19085

[Achilles1515]

The CDK drag-drop library uses directive host bindings for setting many of the CSS classes.

e.g.

@Directive({
  selector: '[cdkDropList], cdk-drop-list',
  //...
  host: {
    'class': 'cdk-drop-list',
    '[id]': 'id',
    '[class.cdk-drop-list-disabled]': 'disabled',
    '[class.cdk-drop-list-dragging]': '_dropListRef.isDragging()',
    '[class.cdk-drop-list-receiving]': '_dropListRef.isReceiving()',
  }
})
export class CdkDropList<T = any> implements OnDestroy {
//...
}

The thing to always keep in mind with dynamic host bindings is that they require change detection to run in order to update and be applied.

The dependence on change detection can create all sorts of bugs and unexpected behavior for users, especially if they are unaware of the ordering in which operations (events emitted, element sizes being measured, etc.) occur in this library and their relation to when change detection is triggered.

The dynamic adding/removing of classes should be removed as host bindings and refactored into the library using standard DOM API with the presumption that the user is modifying element dimensions with these styling classes.

Tldr; Dynamic host bindings are fine for your own app, but don't use them in a general purpose library. I've been meaning to post more about this and maybe make a PR, but haven't gotten around to it yet.

Anyway, here is a modified StackBlitz with the behavior you are looking for.

[crisbeto]

Duplicate of #14703.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}