components icon indicating copy to clipboard operation
components copied to clipboard

CDK Drag Drop issues with nested lists

Open shesse opened this issue 5 years ago • 45 comments

Reproduction

https://stackblitz.com/edit/angular-drag-and-drop-child-groups-fxzjja?file=app%2Fcdk-drag-drop-connected-sorting-group-example.html

Steps to reproduce:

  1. Try to drag element "Brush teeth" to before "Drive to office" or before "Walk dog"
  2. this will not be possible

Expected Behavior

Drag / Drop to all lists contained in cdkDropListConnectedTo

Actual Behavior

Items from inner Lists may only be dropped to outer lists, not to sibling or their own lists

Environment

  • Angular: 8.1.2
  • CDK/Material: 8.1.2
  • Browser(s): Firefox / Chrome
  • Operating System (e.g. Windows, macOS, Ubuntu): Debian Linux, Windows

Additional Info

When using CDK drag / drop (8.0.0 up to and including 8.1.2) with nested lists, two issues arise that prevent an easy use of the feature:

a) dragging does not work from inner list to inner list

  • See https://stackblitz.com/edit/angular-drag-and-drop-child-groups-fxzjja?file=app%2Fcdk-drag-drop-connected-sorting-group-example.html

  • When dragging an inner item (e.g. Brush teeth) it is only possible to drop it in the outer list, not in its own list and not in its sibling list.

  • It turns out, that order in cdkDropListConnectedTo is important: when I reverse the items, it will partially work: See https://stackblitz.com/edit/angular-drag-and-drop-child-groups-mxrkae?file=app%2Fcdk-drag-drop-connected-sorting-group-example.html

  • Still, it is not possible to drop an item from an inner list in into its own list

b) dragging does not work in the drop item's source list

  • See above

  • You may find a hack for this in https://stackblitz.com/edit/angular-drag-and-drop-child-groups-35em6n?file=app/cdk-drag-drop-connected-sorting-group-example.html

Explanation and proposed solution.

For above case a) mentioning it in the documentation may be sufficient - it can be influenced from the outside. However, a more intelligent solution (e.g. identifying the toplevel sublist) would be nice.

For case b), filtering out the source list in src/cdk/drag-drop/directives/drop-list.ts seems to cause the issue: ref.connectedTo(siblings.filter(drop => drop && drop !== this).map(list => list._dropListRef)) My hack replaces this by an unfiltered list - in quite an ugly manner.

shesse avatar Aug 02 '19 20:08 shesse

it doesnt work well, cant get needed element index in nested array.

denkerny avatar Jun 14 '20 14:06 denkerny

+1

james-logan avatar Jun 30 '20 19:06 james-logan

Setting as a P2 based on the number of duplicate issue we get about this.

crisbeto avatar Jul 12 '20 09:07 crisbeto

From @matthewerwin in #19085:

Reproduction

Use StackBlitz to reproduce your issue:

https://stackblitz.com/edit/angular-rf6gg6

Steps to reproduce:

  1. Look at the stack blitz.
  2. Markup has an effect on ability to even start a drag without any console or compile indicator that cdkDrag and cdkDropList cannot be on the same drag element (they could be in v8 --v9 allows them on the same container for the "drop element")
  3. Exit/Enter aren't reliably detected based on the client-rect

Expected Behavior

What behavior were you expecting to see?

  • Drop zone container should always be detected as soon as the mouse goes over the element.
  • If use of cdkDrag/cdkDropList combo only works in certain situations (e.g. codebase looks for this._container on a dragref in v9...which appears to only get set if cdkDropList is on a parent element). That should either be documented and also the compiler should write an error to the console...or the code should be adjusted to set this._container to the element itself to handle the directive combo on the same element.

Actual Behavior

What behavior did you actually see?

  • No errors to console or at compile time with directives appended in any fashion.
  • v9 does not detect a drop-zone accurately at all for entry or exit. Shaking the mouse a bunch over drop zones or redragging repeatedly will randomly then detect it correctly...though continuing to drag around shows the same inability to detect the drop-zones.

crisbeto avatar Jul 12 '20 09:07 crisbeto

+1

f1nality avatar Jul 29 '20 15:07 f1nality

So it seems like there is some internal priority here. I've gotten pretty decent results with sorting the lists by dom depth as a workaround:

    this.connectedDroplists$ = this._connectedDroplists$.pipe(
      debounceTime(16),
      tap((connectedDropLists) => {
        // sort the lists by depth to prefer deeper lists
        connectedDropLists.sort((a, b) => {
          return (
            this._getDepth(b.element.nativeElement) -
            this._getDepth(a.element.nativeElement)
          );
        });
      }),
      shareReplay(1)
    ) as BehaviorSubject<CdkDropList[]>;

~~It seems that no matter what I do, I can't seem to get it to re-order within the source droplist where I grabbed an item from.~~

Sorting the droplists by element depth and using the enforce hack that @shesse has provided, ~~I have gotten an excellent result even with completely overlapping nested drop lists~~ (looks like I had a gap that allowed for me to add to the parent). Thank you @shesse!

I suppose the reversing makes sense because the deeper the list is the later it would be registered (resulting it to be at the end).

Oct-21-2020 14-21-08

admosity avatar Oct 21 '20 15:10 admosity

Hi everyone,

I ran into this issue a few days ago and decided to make an attempt at fixing it :-) I have tried to summarise my "analysis" of the issue and a proposal for how to solve it below. I apologise for - to some extent - repeating what has already been said above. I have also attached "Monkey Patch" that seems to fix the issue for Angular Material v11.0.3. I will try to transform it into a pull request shortly.

The main issue seems to be with the implementation of _getSiblingContainerFromPosition in DropListRef which is used by _updateActiveDropContainer in DragRef to identify whether a draggable item is being moved over a new (and connected) drop container and, if it is, which drop container the item is being moved over.

Based on the code and comments in _updateActiveDropContainer (which is the only place where _getSiblingContainerFromPosition is called), _getSiblingContainerFromPosition is expected to return the DropListRef for the drop container that the item is being moved over, provided that it is not the drop container that it currently belongs to. The method is expected to return 'undefined' if the item is being moved over the current drop container or if it is being moved over something that is not a drop container.

The current implementation of _getSiblingContainerFromPosition does this by returning the first connected drop container ("sibling") in the list of siblings that has a client rect that contains the current position of the item being dragged and for which enterPredicate returns true (I know this is somewhat simplified, but the still argument holds). This approach works perfectly well as long the client rects of the drop containers are not overlapping.

However, when drop containers are nested (and therefore overlapping), this causes two problems:

  1. If an outer drop container is listed before an inner drop container in the list of siblings, _getSiblingContainerFromPosition will return the outer drop container when the item is moved over the inner container. Hence, the list of siblings must be ordered to list inner drop containers before outer drop containers (as mentioned above)
  2. As the list of siblings does not include the current drop container ("this"), _getSiblingContainerFromPosition will always return the outer drop container when an item of the inner drop container is dragged over the inner container. As a result, it is not possible to re-order items in an inner drop container.

The first issue can be addressed by ordering the items of 'cdkDropListConnectedTo' (as mentioned above). The current drop container can, however, not be added to siblings due to the code in _setupInputSyncSubscription of DropList that actively removes 'this' from the list (as pointed out by @shesse). The hack described by @shesse above addresses this issue by forcing the 'this' entry back into the siblings list. This approach does, however, bring the risk of breaking other code as the siblings list is clearly not intended to include 'this'.

My proposal would be to fix the issue by rewriting _getSiblingContainerFromPosition such that it correctly handles nested drop containers without any assumptions on the order of the siblings list. This could be done in the following way:

  • Create a list containing all siblings and 'this'
  • Filter the list so that it only contains those drop containers that has a client rect that contains the current item position
  • Sort the remaining items based on the DOM hierarchy so that outer drop containers appear before the inner drop containers that they contain
  • Extract the last item of the sorted list
  • Check whether the extracted item is indeed a match using _canReceive
  • if _canReceive returns true, return the extracted item otherwise return 'undefined'

I have created a "Monkey Patch" that seems to work with Angular Material version 11.0.3 (attached). It should be straight forward to transform this into a pull request. I will gladly do so (but never having done a pull request before, I'll have to read up on how to do it)

nested-drag-drop-patch.ts.zip

I suspect thet the code breaks more than one Angular Material coding guideline. It is also a quick write-up so I would not be surprised if there are some issues that need to be resolved. A proper code review might be in order ... :-)

soren-petersen avatar Jan 08 '21 23:01 soren-petersen

3 years ago I tried to use drag-drop, but got stuck, some issues were closed due to inactivity. I might have a need in drag-drop in half a year, maybe I will immediately look for another implementation. So I am far off, what is currently implemented or which issues are open and solved, and if this is the correct place for:

  • programmatic callback if it is allowed to drop

FritzHerbers avatar Jan 09 '21 08:01 FritzHerbers

@FritzHerbers

I propose you start by browsing through the excellent documentation for CDK Drag and Drop. I think you will find that the drag-drop feature has improved significantly over the last couple of years. You will likely also find the answer to your callback question there. Have a look at cdkDropListEnterPredicate and cdkDropListSortPredicate.

The issue tracker and this particular issue is, however, not the right place for a general discussion about the state of cdk/drag-drop nor your specific question of support for a programatic callback. If you have further questions, community support requests can be submitted at StackOverflow or in the Angular Material gitter channel.

Please refer to the official instruction for support questions for more details.

soren-petersen avatar Jan 09 '21 14:01 soren-petersen

hi @soren-petersen. can you attach stackblitz link for the same. It will be very helpful. thanks

Akhil-Myadarapu avatar Jan 12 '21 07:01 Akhil-Myadarapu

Hi @Akhil-Myadarapu,

I'm sorry, but I really do not have the time to put together a presentable demo right now. Feel free to put one up if you have more time on your hands than I.

In order to use the "monkey patch" that I attached in a previous post, you only need to import the "installPatch" function from the module:

import { installPatch } from './nested-drag-drop-patch'

and then call it at the root level of your .ts file:

installPatch();

Apart from that, you need to set up a nested tree with cdkDropList and cdkDrop in your template. Remember to use cdkDropListConnectedTo to connect all the drop lists. Using cdkDropListGroup will not work for a nested setup.

You might find that the patch generates some warnings when running lint. These have been fixed in the pull request. Have a look at that if you want the latest version of the fix.

soren-petersen avatar Jan 12 '21 14:01 soren-petersen

@Akhil-Myadarapu, I added the monkey patch to @shesse's original StackBlitz, and then replaced its content with the method bodies from the PR (commit d3690c3):

It works pretty good!

@soren-petersen During dragging, there's some trouble transitioning to a nested list (coming from the top, it doesn't change until the 2nd or 3rd item down; coming from the bottom it wants to drop before the nested list for some pixels, than switches to into.) Not sure if I should make the comments in the PR itself as well?

jneuhaus20 avatar Jan 20 '21 16:01 jneuhaus20

@soren-petersen I've used the zip.file to patch the cdk and it does solve the original issue here.

https://stackblitz.com/edit/angular-10-clarity-4-dragdrop-nested-with-fix

However dragging an item from a child to it's parent seems to have very narrow window. In my example the preview element has a height of 20px. Without the patch, the window works as expected (with the bug of this issue of course). With the patch the window seems to be only like a pixel or so.

aavelyn avatar Feb 07 '21 20:02 aavelyn

So it seems like there is some internal priority here. I've gotten pretty decent results with sorting the lists by dom depth as a workaround:

    this.connectedDroplists$ = this._connectedDroplists$.pipe(
      debounceTime(16),
      tap((connectedDropLists) => {
        // sort the lists by depth to prefer deeper lists
        connectedDropLists.sort((a, b) => {
          return (
            this._getDepth(b.element.nativeElement) -
            this._getDepth(a.element.nativeElement)
          );
        });
      }),
      shareReplay(1)
    ) as BehaviorSubject<CdkDropList[]>;

~It seems that no matter what I do, I can't seem to get it to re-order within the source droplist where I grabbed an item from.~

Sorting the droplists by element depth and using the enforce hack that @shesse has provided, ~I have gotten an excellent result even with completely overlapping nested drop lists~ (looks like I had a gap that allowed for me to add to the parent). Thank you @shesse!

I suppose the reversing makes sense because the deeper the list is the later it would be registered (resulting it to be at the end).

Oct-21-2020 14-21-08

Hello admosiry,

Is there any demo for the image provided? I am looking to do something similar. I am using flex to define double/single columns and I am having issues while dragging. Elements flipping while dragging

stefan0s avatar Feb 17 '21 19:02 stefan0s

thanks @soren-petersen ! Your patch just saved my day !

pdura avatar Mar 17 '21 17:03 pdura

The unability to support sorting in nested lists (without any monkey patch) , is there any plan to fixed it for the upcoming Nov release angular 13?

hannah23280 avatar Sep 24 '21 13:09 hannah23280

It's getting tiring to manually tweak literally every frontend library there is. If you guys implement this one you will probably be the first instance of a library i didn't have to hammer down to my needs

Go down in history and implement this! Pretty please :cry:

EmaGht avatar Oct 07 '21 16:10 EmaGht

Hi everyone,

I ran into this issue a few days ago and decided to make an attempt at fixing it :-) I have tried to summarise my "analysis" of the issue and a proposal for how to solve it below. I apologise for - to some extent - repeating what has already been said above. I have also attached "Monkey Patch" that seems to fix the issue for Angular Material v11.0.3. I will try to transform it into a pull request shortly.

The main issue seems to be with the implementation of _getSiblingContainerFromPosition in DropListRef which is used by _updateActiveDropContainer in DragRef to identify whether a draggable item is being moved over a new (and connected) drop container and, if it is, which drop container the item is being moved over.

Based on the code and comments in _updateActiveDropContainer (which is the only place where _getSiblingContainerFromPosition is called), _getSiblingContainerFromPosition is expected to return the DropListRef for the drop container that the item is being moved over, provided that it is not the drop container that it currently belongs to. The method is expected to return 'undefined' if the item is being moved over the current drop container or if it is being moved over something that is not a drop container.

The current implementation of _getSiblingContainerFromPosition does this by returning the first connected drop container ("sibling") in the list of siblings that has a client rect that contains the current position of the item being dragged and for which enterPredicate returns true (I know this is somewhat simplified, but the still argument holds). This approach works perfectly well as long the client rects of the drop containers are not overlapping.

However, when drop containers are nested (and therefore overlapping), this causes two problems:

  1. If an outer drop container is listed before an inner drop container in the list of siblings, _getSiblingContainerFromPosition will return the outer drop container when the item is moved over the inner container. Hence, the list of siblings must be ordered to list inner drop containers before outer drop containers (as mentioned above)
  2. As the list of siblings does not include the current drop container ("this"), _getSiblingContainerFromPosition will always return the outer drop container when an item of the inner drop container is dragged over the inner container. As a result, it is not possible to re-order items in an inner drop container.

The first issue can be addressed by ordering the items of 'cdkDropListConnectedTo' (as mentioned above). The current drop container can, however, not be added to siblings due to the code in _setupInputSyncSubscription of DropList that actively removes 'this' from the list (as pointed out by @shesse). The hack described by @shesse above addresses this issue by forcing the 'this' entry back into the siblings list. This approach does, however, bring the risk of breaking other code as the siblings list is clearly not intended to include 'this'.

My proposal would be to fix the issue by rewriting _getSiblingContainerFromPosition such that it correctly handles nested drop containers without any assumptions on the order of the siblings list. This could be done in the following way:

  • Create a list containing all siblings and 'this'
  • Filter the list so that it only contains those drop containers that has a client rect that contains the current item position
  • Sort the remaining items based on the DOM hierarchy so that outer drop containers appear before the inner drop containers that they contain
  • Extract the last item of the sorted list
  • Check whether the extracted item is indeed a match using _canReceive
  • if _canReceive returns true, return the extracted item otherwise return 'undefined'

I have created a "Monkey Patch" that seems to work with Angular Material version 11.0.3 (attached). It should be straight forward to transform this into a pull request. I will gladly do so (but never having done a pull request before, I'll have to read up on how to do it)

nested-drag-drop-patch.ts.zip

I suspect thet the code breaks more than one Angular Material coding guideline. It is also a quick write-up so I would not be surprised if there are some issues that need to be resolved. A proper code review might be in order ... :-)

Really helpful! Thank you!

mironante avatar Nov 02 '21 04:11 mironante

Hi everyone,

I ran into this issue a few days ago and decided to make an attempt at fixing it :-) I have tried to summarise my "analysis" of the issue and a proposal for how to solve it below. I apologise for - to some extent - repeating what has already been said above. I have also attached "Monkey Patch" that seems to fix the issue for Angular Material v11.0.3. I will try to transform it into a pull request shortly.

The main issue seems to be with the implementation of _getSiblingContainerFromPosition in DropListRef which is used by _updateActiveDropContainer in DragRef to identify whether a draggable item is being moved over a new (and connected) drop container and, if it is, which drop container the item is being moved over.

Based on the code and comments in _updateActiveDropContainer (which is the only place where _getSiblingContainerFromPosition is called), _getSiblingContainerFromPosition is expected to return the DropListRef for the drop container that the item is being moved over, provided that it is not the drop container that it currently belongs to. The method is expected to return 'undefined' if the item is being moved over the current drop container or if it is being moved over something that is not a drop container.

The current implementation of _getSiblingContainerFromPosition does this by returning the first connected drop container ("sibling") in the list of siblings that has a client rect that contains the current position of the item being dragged and for which enterPredicate returns true (I know this is somewhat simplified, but the still argument holds). This approach works perfectly well as long the client rects of the drop containers are not overlapping.

However, when drop containers are nested (and therefore overlapping), this causes two problems:

  1. If an outer drop container is listed before an inner drop container in the list of siblings, _getSiblingContainerFromPosition will return the outer drop container when the item is moved over the inner container. Hence, the list of siblings must be ordered to list inner drop containers before outer drop containers (as mentioned above)
  2. As the list of siblings does not include the current drop container ("this"), _getSiblingContainerFromPosition will always return the outer drop container when an item of the inner drop container is dragged over the inner container. As a result, it is not possible to re-order items in an inner drop container.

The first issue can be addressed by ordering the items of 'cdkDropListConnectedTo' (as mentioned above). The current drop container can, however, not be added to siblings due to the code in _setupInputSyncSubscription of DropList that actively removes 'this' from the list (as pointed out by @shesse). The hack described by @shesse above addresses this issue by forcing the 'this' entry back into the siblings list. This approach does, however, bring the risk of breaking other code as the siblings list is clearly not intended to include 'this'.

My proposal would be to fix the issue by rewriting _getSiblingContainerFromPosition such that it correctly handles nested drop containers without any assumptions on the order of the siblings list. This could be done in the following way:

  • Create a list containing all siblings and 'this'
  • Filter the list so that it only contains those drop containers that has a client rect that contains the current item position
  • Sort the remaining items based on the DOM hierarchy so that outer drop containers appear before the inner drop containers that they contain
  • Extract the last item of the sorted list
  • Check whether the extracted item is indeed a match using _canReceive
  • if _canReceive returns true, return the extracted item otherwise return 'undefined'

I have created a "Monkey Patch" that seems to work with Angular Material version 11.0.3 (attached). It should be straight forward to transform this into a pull request. I will gladly do so (but never having done a pull request before, I'll have to read up on how to do it)

nested-drag-drop-patch.ts.zip

I suspect thet the code breaks more than one Angular Material coding guideline. It is also a quick write-up so I would not be surprised if there are some issues that need to be resolved. A proper code review might be in order ... :-)

Thank you so much for this patch, you're an absolute legend!

willehpeh avatar Feb 07 '22 11:02 willehpeh

Could we have an update from the angular contributors POV? What's the status of #21526 ? It would be nice to get this moved forward.

wawyed avatar Mar 31 '22 10:03 wawyed

@crisbeto - drop list should definitely have the option to count itself when searching for containers from position (and disable this filtering). This will give us an opportunity to specify order in case of overlapping drop lists.

also, I prepared a clone of @shesse StackBlitz with a different fix. Fix that overwrites _getSiblingContainerFromPosition to search over custom-defined list of containers/siblings. Like this, you should be able to keep the order you specified and mitigate side effects.

https://stackblitz.com/edit/angular-drag-and-drop-child-groups-9bmj6t?file=app%2Fcdk-drag-drop-connected-sorting-group-example.ts

ZycaR avatar Apr 29 '22 23:04 ZycaR

Really would be nice if the "monkey patch" PR could be looked at again by maintainers and merged....

JaxonWright avatar May 05 '22 20:05 JaxonWright

if cdk implement flex layout would be great. like this.

drag-and-drop

LinboLen avatar May 09 '22 14:05 LinboLen

@crisbeto - drop list should definitely have the option to count itself when searching for containers from position (and disable this filtering). This will give us an opportunity to specify order in case of overlapping drop lists.

also, I prepared a clone of @shesse StackBlitz with a different fix. Fix that overwrites _getSiblingContainerFromPosition to search over custom-defined list of containers/siblings. Like this, you should be able to keep the order you specified and mitigate side effects.

https://stackblitz.com/edit/angular-drag-and-drop-child-groups-9bmj6t?file=app%2Fcdk-drag-drop-connected-sorting-group-example.ts

Thanks A LOT for the given fix! I'm so happy now

Qrauzer avatar May 25 '22 05:05 Qrauzer

@crisbeto - drop list should definitely have the option to count itself when searching for containers from position (and disable this filtering). This will give us an opportunity to specify order in case of overlapping drop lists.

also, I prepared a clone of @shesse StackBlitz with a different fix. Fix that overwrites _getSiblingContainerFromPosition to search over custom-defined list of containers/siblings. Like this, you should be able to keep the order you specified and mitigate side effects.

https://stackblitz.com/edit/angular-drag-and-drop-child-groups-9bmj6t?file=app%2Fcdk-drag-drop-connected-sorting-group-example.ts

Hi there all, just want to throw this in for anyone who is doing something similar but whose list isn't a simple two dimensional string array(s). This is based off of ZycaR's stackblitz so I tried to keep all the class names and what not the same for easier reference.

My list contains an array of objects, and those objects can have a child array of objects (but only some of them if they are a category). So I had to do mine slightly different, but struggled with it for a while. Hence why I'm throwing this in for anyone who is struggling to do the same.

<div cdkDropListGroup>
  <div class="example-container">

    <div cdkDropList [cdkDropListData]="features" class="example-list" (cdkDropListDropped)="drop($event)"
      [cdkDropListConnectedTo]="dls">
      <div class="example-box" *ngFor="let item of features" cdkDrag>
        <div *ngIf="!item.isCategory; else arrayView">{{item.name}}</div>
        <ng-template #arrayView>
          <div class="example-container">
            <div cdkDropList [cdkDropListData]="item" class="example-list" (cdkDropListDropped)="childArrayDrop($event)"
              [cdkDropListConnectedTo]="dls">
              {{item.name}}
              <div class="example-box" *ngFor="let innerItem of item.children" cdkDrag>{{innerItem.name}}</div>
            </div>
          </div>
        </ng-template>
      </div>
    </div>
  </div>

</div>

Main thing to note in the HTML is the two different (cdkDropListDropped) functions for main and child arrays. Also had to change innerItem of item to innerItem of item.children (to be clear children is in reference to that object's child list).

drop(event: CdkDragDrop<any[]>) {
    const childArrName = 'children';
    if (event.previousContainer === event.container) {
      moveItemInArray(
        event.container.data,
        event.previousIndex,
        event.currentIndex
      );
    } else {
      transferArrayItem(
        event.previousContainer.data[childArrName],
        event.container.data,
        event.previousIndex,
        event.currentIndex
      );
    }
    this.orderHasChanged();
  }

  childArrayDrop(event: CdkDragDrop<any[]>) {
    const childArrName = 'children';
    if (event.previousContainer === event.container) {
      moveItemInArray(
        event.container.data[childArrName],
        event.previousIndex,
        event.currentIndex
      );
    } else {
      transferArrayItem(
        event.previousContainer.data,
        event.container.data[childArrName],
        event.previousIndex,
        event.currentIndex
      );
    }
    this.orderHasChanged();
  }

The separate functions look for the child array inside of the event.container.data based on what array/object the item is being dropped in to, because the container data can be the object itself, therefore throwing off transferItemArray or moveItemArray code.

I.E. drop() is for moving items in the parent array and dropping from child to parent, and childArrayDrop is for moving items in the child array and dropping from parent to child.

These seem like a really simple fix but it took me a LONG time (embarrassingly long) and lots of browser crashes to figure out.

I'm in no way a cdkDragDrop expert (first time using it really), so I'm sure this could be approved upon. If you have suggestions you can reply, otherwise it works for what I need it for. Next plan is to make it work for a multi dimensional list, since this one is probably stuck to just a two level array.

Edit: I had to make a small addendum to the childArrayDrop function, this handles when an item is drag and dropped from one child to another.

childArrayDrop(event: CdkDragDrop<FeatureList[]>) {
    const childArrName = 'children';
    if (event.previousContainer === event.container) {
      moveItemInArray(
        event.container.data[childArrName],
        event.previousIndex,
        event.currentIndex
      );
    } else {
      if (
        !Array.isArray(event.previousContainer.data) &&
        !Array.isArray(event.container.data)
      ) {
        transferArrayItem(
          event.previousContainer.data[childArrName],
          event.container.data[childArrName],
          event.previousIndex,
          event.currentIndex
        );
      }
      transferArrayItem(
        event.previousContainer.data,
        event.container.data[childArrName],
        event.previousIndex,
        event.currentIndex
      );
    }
    this.orderHasChanged();
  }

MichaelChappell0117 avatar Aug 12 '22 04:08 MichaelChappell0117

Any updates on this at all? Would be nice to have support for nested drop-lists...

wawyed avatar Sep 15 '22 16:09 wawyed

Just run into this myself, would be great to have please :)

LeahPike avatar Sep 26 '22 16:09 LeahPike

I have solution. So I have multiple, dynamic nested lists (I really don't know in ahead how many there will be). In the drag&drop code I've noticed they are removing "itself" from siblings list wherever they can :) so I did this:

  public ngAfterViewInit() {
    const dropListRef = this.cdkDropList._dropListRef;
    const originalConnectedTo: any = dropListRef.connectedTo;

    dropListRef['connectedTo'] = ((connectedTo) => {
      originalConnectedTo.apply(dropListRef, [connectedTo]);

      const targetIndex = this.allDropListsIds.findIndex(id => id === this.listId);
      dropListRef['_siblings'].splice(targetIndex, 0, dropListRef);
      return dropListRef;
    }) as any;
  }

Where allDropListsIds is the list of ids for every list we want to be connected Works fine for now :)

slavede avatar Oct 20 '22 08:10 slavede

@slavede that's great! Could you put together a Stackblitz with that for everyone?

BenRacicot avatar Oct 20 '22 12:10 BenRacicot

I think @slavede 's work is awesome, but we really need to pressure the CDK team to merge a fix for this. It's been over 3 years now and it's still broken.

Does anyone have any idea who we need to bribe to actually get them to pay attention to closing out bugs rather than focusing on new features?

SkoZombie avatar Oct 21 '22 00:10 SkoZombie