CdkDragDrop.previousIndex is never being updated
#18482
Assignees
Comments
crisbeto
added
has pr
P2
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Feb 13, 2020
Currently the CDK drag&drop is set up so that it keeps track of the items inside each drop list via `ContentChildren`, however this doesn't work properly inside of a transplanted view (e.g. in the header of a `mat-table`). There are two main problems inside transplanted views: 1. On the first change detection the `ContentChildren` query may be empty, even though the items exist. Usually they're fine on the second run, but that may be too late, because the user could've started dragging already. 2. Even if we somehow ensured that the `ContentChildren` is up-to-date when dragging starts, Angular won't update the order of the transplanted view items in the query once they're shuffled around. To work around these limitations and to make it possible to support more advanced usages like in `mat-table`, these changes switch to keeping track of the items using DI. Whenever an item is created or destroyed, it registers/deregisters itself with the closest drop list. Since the insertion order can be different from the DOM order, we use `compareDocumentPosition` to sort the items right before dragging starts. Fixes angular#18482.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Feb 13, 2020
Currently the CDK drag&drop is set up so that it keeps track of the items inside each drop list via `ContentChildren`, however this doesn't work properly inside of a transplanted view (e.g. in the header of a `mat-table`). There are two main problems inside transplanted views: 1. On the first change detection the `ContentChildren` query may be empty, even though the items exist. Usually they're fine on the second run, but that may be too late, because the user could've started dragging already. 2. Even if we somehow ensured that the `ContentChildren` is up-to-date when dragging starts, Angular won't update the order of the transplanted view items in the query once they're shuffled around. To work around these limitations and to make it possible to support more advanced usages like in `mat-table`, these changes switch to keeping track of the items using DI. Whenever an item is created or destroyed, it registers/deregisters itself with the closest drop list. Since the insertion order can be different from the DOM order, we use `compareDocumentPosition` to sort the items right before dragging starts. Fixes angular#18482.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Feb 13, 2020
Currently the CDK drag&drop is set up so that it keeps track of the items inside each drop list via `ContentChildren`, however this doesn't work properly inside of a transplanted view (e.g. in the header of a `mat-table`). There are two main problems inside transplanted views: 1. On the first change detection the `ContentChildren` query may be empty, even though the items exist. Usually they're fine on the second run, but that may be too late, because the user could've started dragging already. 2. Even if we somehow ensured that the `ContentChildren` is up-to-date when dragging starts, Angular won't update the order of the transplanted view items in the query once they're shuffled around. To work around these limitations and to make it possible to support more advanced usages like in `mat-table`, these changes switch to keeping track of the items using DI. Whenever an item is created or destroyed, it registers/deregisters itself with the closest drop list. Since the insertion order can be different from the DOM order, we use `compareDocumentPosition` to sort the items right before dragging starts. Fixes angular#18482.
andrewseguin
pushed a commit
that referenced
this issue
Feb 20, 2020
Currently the CDK drag&drop is set up so that it keeps track of the items inside each drop list via `ContentChildren`, however this doesn't work properly inside of a transplanted view (e.g. in the header of a `mat-table`). There are two main problems inside transplanted views: 1. On the first change detection the `ContentChildren` query may be empty, even though the items exist. Usually they're fine on the second run, but that may be too late, because the user could've started dragging already. 2. Even if we somehow ensured that the `ContentChildren` is up-to-date when dragging starts, Angular won't update the order of the transplanted view items in the query once they're shuffled around. To work around these limitations and to make it possible to support more advanced usages like in `mat-table`, these changes switch to keeping track of the items using DI. Whenever an item is created or destroyed, it registers/deregisters itself with the closest drop list. Since the insertion order can be different from the DOM order, we use `compareDocumentPosition` to sort the items right before dragging starts. Fixes #18482.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It looks like
CdkDragDrop.previousIndexis never being updated. It always reports the original index - rather than the previous - of the thing being dragged.Reproduction
#18456 reproduces this issue.
Expected Behavior
CdkDragDrop.previousIndexhas the "before this drag" index value of the thing I'm dragging, rather than the "before any drags occurred" index value of the thing I'm dragging.Actual Behavior
CdkDragDrop.previousIndexhas the "before any drags occurred" index value of the thing I'm dragging.Environment
The text was updated successfully, but these errors were encountered: