Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(DragDropModule): Allow manual triggering of CdkDropList and CdkDragElement size recomputation #25045

Open
peternixey opened this issue Jun 9, 2022 · 1 comment
Labels
area: cdk/drag-drop feature This issue represents a new feature or feature request rather than a bug or bug fix P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@peternixey
Copy link

peternixey commented Jun 9, 2022

Feature Description

From what I can tell about how Material Drag and Drop works, on drag start, the size of all drag elements is calculated and then stored. I assume that it's only done once to optimise performance which makes sense.

However, building higher levels of UX responsiveness into DropLists and Drag items often means altering their size. The particular example that I am working with at the moment is that of enlarging a drop area when the drag begins.

I would like to be able to manually trigger the CdkDropList to re-compute the height of both itself and any components within it (or at the very least just itself) so that it can respond to changes in the UI.

e.g. to have a method like: cdkDropList.recomputeSizes()

Use Case

To make it easier for users to drag items into an empty list, I'd like to enlarge a target drop Area on drag start. And so on drag start, I apply a class to the DropList that changes its height. The problem is that while the DropList itself grows in height, the effective drop-zone does not. It seems that although the CdkDropList has increased in height, Angular is using its own internal calculation of the original height to determine the dropZone.

Updated.drag.recording.mov

In the recording above you can see how the drop area is enlarged on drag start. The cdkDropList element is indicated using the green dotted line.

However you can see that although the DropList is enlarged to make it easier to drop the CdkDrag item into it, the majority of the list area will not receive the CdkDrag item. In fact it seems that the DropList will only receive the CdkDrag item once it enters the drop area that the list originally covered before it was enlarged.

The same effect is not observed when the minimum height set statically to be the larger size:

fixed.min-height.mov

I would like to be able to trigger the list to recompute its own area so that it can behave correctly relative to its new, larger size.

Bonus extra

Creating advanced drag and drop behaviour can require resizing items in the list as well as just the list itself. It would be really nice to be able to trigger the DropList to be able to recompute the size of all elements and not just the drop area.

An example of this is collapsing elements in the list when a drag begins. The example below illustrates using a single-tiered DropList to mimic the behaviour of a nested list. The mimicry is done by removing the child elements entirely from the list before the drag begins,

drag.and.drop.-.good.mov

Although the example above illustrates what looks like a nested list, it is in fact just a single-level list that uses indentation to create the illusion of nesting. The "child" nodes are removed from the list on drag start and then re-inserted after drag finish. Happily, this seems to work robustly.

However it would be extremely useful to be able to change the items in the list during the drag process itself. Imagine for instance dragging an item over a folder that you wish to open. I can imagine that inserting items into a list during drag might be very complicated to code. However, a simple workaround could be achieved by having the items in the list from the start but with zero height and then enlarging their height when the parent folder opens.

However this would again require the list to recompute the sizing of all elements so that we don't end up with an effect similar to that below. In this example, the child nodes aren't consistently removed from the tree before CdkDrag computes the item heights. And so the DropList calculates the sizing of all elements within it and only then are some of them removed - which results in the peculiar effect we see.

drag.and.drop.-.not.working.mov

If my understanding of the system is correct then all of this could potentially be worked around if it were possible to manully trigger recomputation of the size and position of CdkDropList and CdkDrag elements

@peternixey peternixey added feature This issue represents a new feature or feature request rather than a bug or bug fix needs triage This issue needs to be triaged by the team labels Jun 9, 2022
@peternixey
Copy link
Author

On expermienting witht this further I can see that Angular does have the ability to recompute sizing, I just need to be able to trigger it.

Adding an item to the resized list and then removing it causes the list size to be recomputed

illustration.of.resize.calculation.mov

The animation above shows how when the drag start triggers the growth of the drop area, Angular lags in its internal understanding of the drop area size.

However... once the item has been dragged into the area and then subsequently removed, re-dragging it into the area delivers the behaviour we expect. The act of Angular adding the item to the list seems to trigger the recomputation of the list size.

I'd love to be able to manually retrigger that computation 🙏🏻

@peternixey peternixey changed the title feat(DragDropModule): Allow manual recomputation of CdkDropList and CdkDragElement sizes feat(DragDropModule): Allow manual triggering of CdkDropList and CdkDragElement size recomputation Jun 10, 2022
@crisbeto crisbeto added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent area: cdk/drag-drop and removed needs triage This issue needs to be triaged by the team labels Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: cdk/drag-drop feature This issue represents a new feature or feature request rather than a bug or bug fix P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

No branches or pull requests

2 participants