Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Ordered + limited live queries commit `loading []` even when the source answers synchronously

Đã đóng
  • Có gì không ổn?
#1,894 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
react, typescript
Lĩnh vực
databases, frontend

Hướng nghiên cứu

Start at OrderedSourceLoader.observe(), especially loadSubset and the initial-load hold, then compare the eager and on-demand paths described in the issue. Run the Vitest/jsdom React probe and inspect tests covering reentrant window moves, sync write-then-throw, and cleanup during settlement. Done means synchronous eager results publish rows without loading [], while explicit window moves, repairs, and on-demand behavior retain current semantics.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Ordered + limited live queries commit loading [] even when the source answers synchronously

Versions: @tanstack/db 0.9.0 → current main (introduced by #1797). 0.8.7 is fine.

Since the OrderedSourceLoader landed, any orderBy().limit() live query commits an empty loading result first, even when the source has already answered the request synchronously. The same query without limit publishes its rows in the first commit.

observe() settles every request through a promise, and the initial-load hold keeps publication back until that promise settles:

const request = settlesAsync ? result : Promise.resolve()
const tracked = request.then(complete, fail)

So a true from loadSubset (eager sync mode, or a warm query-collection cache) still costs at least one microtask before anything publishes. In React, that means the first render is loading [], and the rows arrive one to two tasks later.

Repro

Commits logged in useLayoutEffect, React 18, @tanstack/react-db 0.4.1:

Source Query 0.8.7 0.9.x
eager localOnlyCollectionOptions, 200 rows where / orderBy / groupBy / findOne rows rows
same orderBy().limit(20) 20 0/loading → 20
queryCollectionOptions, syncMode: 'on-demand', warm cache, no fetch where — 67
same orderBy().limit(20) — 0/loading → 20

The last row is the one I'd expect people to hit: remounting a sorted, paginated list over a query collection with a hot cache shows a loading state without fetching anything. TanStack Query would hand back the cached result synchronously there, and query-db-collection's loadSubset does return true for it. The ordered loader discards that.

Probe (vitest + jsdom, @testing-library/react):

function Live({ out }) {
  const r = useLiveQuery(
    (q) => q.from({ e: events }).orderBy(({ e }) => e.n).limit(20),
    [],
  )
  useLayoutEffect(() => { out.push(`${r.data.length}/${r.status}`) })
  return null
}
// mount, remount → out: ['0/loading', '20/ready'] on every mount

Impact

  • useLiveInfiniteQuery always adds limit, so every infinite list renders empty on mount and on every dependency change. On top of that, its window starts on commit (#1675; separate issue).
  • Code that makes a decision on the first render reads it as "no rows". We had a route that redirected away from a tab whenever its list rendered empty; since 0.9 it redirected every time.

Proposed fix

A PR follows for the safe subset: when the source is eager (every request is served from rows the collection already holds, so it can neither write later nor fail), and the request is not an explicit window move or a repair, observe() settles in the same pass. On-demand sources, window moves and repairs keep the current behaviour.

The general case, any synchronously satisfied request including a warm query cache, is the one users will actually notice. I tried settling every synchronous result inline, and it breaks about 60 tests (reentrant window moves, sync write-then-throw, cleanup during settlement), so it needs someone who knows the reentrancy model better than I do. Happy to help test.

Ngôn ngữ chính
TypeScript
Star
3.9k
Fork
267
Merge trung bình
1 ngày 11 giờ
Pull request đã merge (30 ngày)
84

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/db

Tất cả issue của TanStack/db

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.