-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Virtualize: Refresh when estimated item size changes. Fixes #25915 #26268
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
Virtualize: Refresh when estimated item size changes. Fixes #25915 #26268
Conversation
// At this point, something unusual has occurred, likely due to misuse of this component. | ||
// Reset the calculated item size to the user-provided item size. | ||
_itemSize = ItemSize; | ||
itemSizeChanged = false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the refactoring here isn't strictly necessary, but I've tidied up the operations so it only deals with the "item size changed" steps in cases where we might be assigning new values to _itemSize
. These refactorings are very safe AFAIK.
|
||
// We don't want to create an infinite rendering loop due to floating point precision limits, | ||
// so only re-render if the item size change is big enough | ||
itemSizeChanged = Math.Abs(_itemSize - previousItemSize) > 0.5f; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the bit I'm a bit nervous about. Might there be some edge case where we create an infinite loop? That is, on every render we compute a slightly different item size, perhaps alternating between two values.
I'm pretty sure I could cause such a problem deliberately if I wanted by putting in some pathological CSS that varies the sizes weirdly. Whether or not that scenario happens to innocent developers acting in good faith is harder to guess.
This is a potential fix for #25915.
This PR is so we can have a conversation about whether to include this fix in 5.0. Personally, I don't think it's a clear-cut decision. We could argue either way. Obviously it's generally good to fix issues, but:
FetchData
table in the default template happen to be 48.89px high!ItemHeight
value to<Virtualize>
instead of relying on it auto-detecting the height. If they do that, the problem won't occur, as far as I can tell.<Virtualize>
. As we all know, virtualization is fundamentally pretty hard to do and cover every edge case when it's not a native feature of the underlying UI technology. I think what we've got is really good and useful, but we should be prepared to refine it further as time goes on.