-
Notifications
You must be signed in to change notification settings - Fork 131
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
Lots of Physical Items generated/No Way to Cap Physical Items #506
Comments
I'm having the same issue when i use the scroll method to go back to the top of the list :( |
Is iron list getting a specific height? I was having a similar issue and this seems to be the cause for me. Now to get it working properly in FF and IE where the scroll seems completely broken |
@moodyjmz That appeared to be the issue, thanks :) 👍 |
Any update on this? I still see this issue while setting a height explicitly. Version 2.0.19. |
I see the same issue with iron-list 3.0.2, specially when item has input fields like paper-input... |
The height can't be %. I don't know of a way to limit physical items. I think the issue of flooding the physical items pool arises as the delta is calculated and _increasePoolIfNeeded debounces itself recursively and asynchronously as a microTask or during the idlePeriod. Basically it will keep running and call itself. If you are able to to use Or extend iron-list and modify _increasePoolIfNeeded to do: _increasePoolIfNeeded(count) {
this.updateViewportBoundaries();
super._increasePoolIfNeeded(count);
} Forcing height related values to be updated, it may help. If you are applying dynamic heights to the list - ie changing numbers of items, you'd need a more involved approach. iron-list has significant holes in it and my suggestions are mere plugs in those holes. |
It does not help for me... I've tried increase denounce period from microTask to timeout.after - 150ms and tried to use 'updateViewportBoundaries' as well it does not help... |
I have added a property: and the logic is - when element has defined outside a value - it means suppress an auto increasing physical elements...and it helps me for now, at least we have approximately limited height of screens use everywhere the property here is a part of code `var autoIncrease = this.defaultPhysicalCount == DEFAULT_PHYSICAL_COUNT
|
Expected outcome
When i am rendering complex items e.g. a Web Components with slots etc, i expect to be able to do this efficiently with a virtual list - iron-list.
In the version 1.X stream of the branch you can set: max-physical-count to control this.
Actual outcome
Instead i find what happens with the more recent versions any since (1.3.15), i find that iron-list seems to uncontrollably create elements, which leads to the browser locking up.
the code now appears to constantly call "_increasePoolIfNeeded" when you are scrolling fast which leads to mass generation of DOM nodes and browser locking up.
I've tried to follow the logic in _increasePoolIfNeeded but its rather messy
Browsers Affected
Polymer Versions
1.x and 2.X
Demo above uses the "collapse" demo from the iron-overlay repository, you can see at some point durin the scrolling the code decide to generate lots of nodes at once, for large lists/complex components this causes heavy browser lag.
Can reproduce with:
https://raw-dot-custom-elements.appspot.com/PolymerElements/iron-list/v2.0.12/iron-list/demo/collapse.html
The more content you have to worse this issue appears to be
The text was updated successfully, but these errors were encountered: