measureElement caches 0 size for nodes that aren't attached yet (Vue: rows stack at start 0 and the list scrolls away on mount)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- frontend, performance
Hướng nghiên cứu
Bắt đầu tại Virtualizer.measureElement và so sánh đường dẫn đo đồng bộ của nó với cách xử lý ResizeObserver hiện có đối với các node đã bị ngắt kết nối. Xác minh rằng các node đã bị tách vẫn giữ kích thước ước tính trong khi tiếp tục được theo dõi, sau đó thêm hoặc chạy một kiểm thử hồi quy bao quát việc đo node đã bị tách, việc gắn lại sau đó và vị trí cuộn được giữ nguyên.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug
Virtualizer.measureElement(node) measures the node synchronously right after observing it, even when the node is not attached to the document yet. A detached node reports offsetHeight === 0, and since there is no cached size on the first measurement, that 0 is stored as the item size.
In Vue this is easy to hit. Function refs run synchronously during patch, so when the rows are created in the same patch as their parent (the sizer is behind v-if and shows up once data is loaded), :ref="(el) => virtualizer.measureElement(el)" is called while the sizer is still detached:
- Every visible row gets size
0and renders atstart: 0, on top of each other. - On the next frame the ResizeObserver reports the real sizes and the rows spread out.
- The list ends up scrolled down (~305px in the repro, row 9 at the top) instead of staying at the top.
The ResizeObserver callback already ignores disconnected nodes (#1135), but the sync path in measureElement doesn't. #1226 only rejects a 0 when there is a previously cached size, so it doesn't cover the first measurement either.
Your minimal, reproducible example
https://stackblitz.com/github/webn00b/tanstack-vue-virtual-detached-measure
Steps to reproduce
- Open the repro. The scroll container is always rendered; the sizer and the rows are behind
v-if="loaded", which flips after a simulated fetch. - Rows are measured with
:ref="(el) => virtualizer.measureElement(el)",estimateSizeis 60. - Check the output under the list: the ref calls log
isConnected: false, offsetHeight: 0, and right afternextTickthe visible items havestart: 0, size: 0. - After the ResizeObserver fires, the list is at
scrollTop ≈ 305.
Expected behavior
Rows keep their estimateSize positions until they are measured, and the list stays at scrollTop: 0.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
- OS: macOS
- Browser: Chrome
Not browser-specific, it comes from when Vue calls function refs.
tanstack-virtual version
@tanstack/vue-virtual 3.13.39, @tanstack/virtual-core 3.17.11
TypeScript version
No response
Additional context
Skipping the sync measurement when !node.isConnected fixes it. The node is still observed, so the first frame uses estimateSize, the ResizeObserver delivers the real size once the node is attached, and the scroll position stays at 0. I have a fix with a regression test and can open a PR.
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.
- Ngôn ngữ chính
- TypeScript
- Star
- 7.1k
- Fork
- 468
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 12
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của TanStack/virtual
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
TanStack/virtual#1257 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của TanStack/virtual
Issue tương tự
-
module-request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ports get and web print 'Port N already in use, trying next...' for every busy port they skipĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
appandflow/stim#1604 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
lingdojo/kana-dojo#31060 · 1 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SSH workspace restore rewrites relative symlinks into the deleted sync-back staging directoryĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
paperclipai/paperclip#14173 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày