-
Notifications
You must be signed in to change notification settings - Fork 6.8k
bug(drag-and-drop): disconnecting drop list is really slow after version 19.1.5 #30737
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Closed
1 task done
Labels
Comments
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Mar 31, 2025
angular#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive. These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting. Fixes angular#30737.
crisbeto
added a commit
that referenced
this issue
Mar 31, 2025
…#30751) #30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive. These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting. Fixes #30737.
crisbeto
added a commit
that referenced
this issue
Mar 31, 2025
…#30751) #30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive. These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting. Fixes #30737. (cherry picked from commit 1372f52)
szoboszlaypali
pushed a commit
to szoboszlaypali/components
that referenced
this issue
Apr 1, 2025
…angular#30751) angular#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive. These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting. Fixes angular#30737.
mistrykaran91
pushed a commit
to mistrykaran91/components
that referenced
this issue
Apr 7, 2025
…angular#30751) angular#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive. These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting. Fixes angular#30737.
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. |
# for free
to subscribe to this conversation on GitHub.
Already have an account?
#.
Labels
Is this a regression?
The previous version in which this bug was not present was
19.1.3
Description
After #30514 , disconnecting long list of drag items slows down browser so much that it freezes. Locally reverting that change fixes the issue and you get the earlier behavior.
The use case may be little bit unconventional, but we have separate list for "items to buy" and then items for being in "shopping basket" (using one of the examples in website). They are in different components and connected by one parent component. Everything works greatly until the "product selection" component is destroyed. It works when there are sane number of items ,say 500. But when there are over 4000 items, the browser becomes unusable.
I'm able to repro this same behavior in Stackblitz. Though, it needs a lot more items before it starts to break: 40000.
Our actual code is years old, so it may be that it would be instructed to write it another way.
Is there a way that
this._syncItemsWithRef();
would not be called for every item in a row if it happens really quickly? Or is there a better way to disconnect the drop lists before the component is destroyed? Or could there be a setting to opt into the old behavior?Reproduction
StackBlitz link: https://1owdqzmq.stackblitz.io
Steps to reproduce:
With smaller array, it's not noticeable at all.
Expected Behavior
It should not be so taxing operation that it basically crashes browser tab
Actual Behavior
Crashes browser tab :/
Environment
The text was updated successfully, but these errors were encountered: