You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Lane assignments should respect measured sizes, not just estimates #1114
#1080 added caching for initial lanes assignment, which introduced a breaking change in functionality where dynamic lane assignments is needed.
As I understand it, estimateSize is meant to provide a rough estimate when the actual size cannot be known beforehand.
While caching lane assignments from estimateSize is good for visual stability by limiting shifts into height changes, It makes dynamic lane assignment impossible, which is core requirement for masonry style layouts. Consumer may need more complex tweaks for achieving this.
If we don't want to change the default behaviour, adding an option to defer lane caching until the first measurement would be very helpful (e.g., deferLaneAssignment.)
Lanes assinged based on estimateSize since v3.13.13 - Left to Right, ignoring measured sizes:
Run pnpm before and restart the dev server (pnpm dev)
You can see how it used to be
Expected behavior
Lanes assigned based on actual measured sizes:
How often does this bug happen?
None
Screenshots or Videos
No response
Platform
macOS (but the issue is platform agonistic)
tanstack-virtual version
v3.13.18 (after v.3.13.12)
TypeScript version
No response
Additional context
No response
Terms & Code of Conduct
I agree to follow this project's Code of Conduct
I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
I've simply implemented deferLaneAssignment in #1115.
That said, we could also consider a caching strategy option instead, which might be more flexible such as:
typeLaneAssignmentCache="estimateSize"|"firstMeasure"|"none";// "estimateSize" - current default behavior (assign based on estimate)// "firstMeasure" - current deferLaneAssignment// "none" - previous default before caching introduced
Would love to hear your thoughts on this direction.
Activity
piecyk commentedon Jan 8, 2026
cc @seob717
2wheeh commentedon Jan 13, 2026
I've simply implemented
deferLaneAssignmentin #1115.That said, we could also consider a caching strategy option instead, which might be more flexible such as:
Would love to hear your thoughts on this direction.