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

Don't keep references to cells not in the 'items' colltection #142

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

pieter-v
Copy link
Contributor

If some items (that are currently visible) are removed from the
‘items’ collection, then they are still referenced in the _cells
property. So they are still in the DOM (display: none).
If afterwards these removed items are destroyed (item.destroy) and a re-rendering
(e.g.: change of screen size) occurs. Then this result in an error:
Assertion Failed: Cannot call writableTag after the object is destroyed.

This pull request removes all cells that are not in the items
collection.

If some items (that are currently visible)  are removed from the
‘items’ collection, then they are still referenced in the _cells
property. So they are still in the DMO (display: none). If afterwards
these removed items are destroyed (item.destroy) and a re-rendering
(e.g.: change of screen size) occurs. Then this result in an error:
Assertion Failed: Cannot call writableTag after the object is destroyed.

This pull request removes all cells that are not in the items
collection.
@@ -187,11 +188,11 @@ export default Ember.Component.extend({
set(cell, 'hidden', false);
cellMap[itemKey] = cell;
} else {
set(cell, 'hidden', true);
set(cell, 'style', 'height: 0; display: none;');
cellsToDelete.push(cell);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been so long but keeping the cell around might have some performance wins if the collection shrinks, but then grows again ( you don't have to pay to re-create the DOM the second time). Rather than deleting the cell could we instead just set item to null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay.
Setting the item to null, solves the problem of keeping a reference to not used items.
But it introduces another problem: the component that is used to render the item should be able to handle 'null'-items.
This moves extra complexity to yield block. So, I think it is better to loose some performance in the shrink-grow scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants