Automatic Query Collection refetch still has no observable result-application settlement
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- sqlite, typescript
- 領域
- database
調査の方向性
Start in the Query Collection implementation where pendingResultApplications is tracked, then inspect collection.utils and the existing utils.refetch barrier. Use the linked downstream patch and regression test as behavioral references, including automatic invalidation/revalidation and unchanged results. Done means a public observable settlement signal covers every automatic query result without changing the explicit refetch barrier.
索引モデルが issue の本文から書いたものです。
説明
Versions
@tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected].
Problem
#1828 was closed after utils.refetch() became an awaitable result-application barrier. That fixes an explicit refetch. An automatic Query Collection refetch (Query invalidation/revalidation) still has no public way for a reactive consumer to tell whether its result has finished applying to collection rows.
With an existing persisted row, hold the SQLite commit that applies a newer fetched result. The Query cache already reports a successful, idle fetch with a newer dataUpdatedAt, while collection.get(key) still returns the old row. The pending application is tracked internally by pendingResultApplications, but collection.utils does not expose it. When the result is identical to existing rows, application completion emits no collection change event, so observing collection changes cannot close the gap either.
Our status hook needs this distinction before it treats collection rows as authoritative for a user decision. We currently patch 1.3.1 to expose isApplyingResult and subscribeResultApplications (start, invalidation, and settlement, including empty diffs): downstream patch and regression test.
Expected
Either a public application-phase state with a subscription, or an observable successful-application event/revision that advances for every automatic query result, including an unchanged result. The explicit utils.refetch() barrier can remain as it is; the missing case is work initiated by the Query Collection itself.
- 主要言語
- TypeScript
- スター
- 3.9k
- フォーク
- 268
- 平均マージ
- 1日 3時間
- マージ済み PR（30日）
- 147
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
TanStack/db のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 50/100
TanStack/db#1992 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
📕documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
db-ux-design-system/core-web#8343 ·
メンテナーはふだん 1 日以内に返信
-
enhancement triage/needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
heygen-com/hyperframes#4944 ·
メンテナーはふだん 1 日以内に返信
-
ai-driven-qa bug claude
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
linagora/twake-calendar-frontend#1493 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
material-extensions/vscode-material-icon-theme#3610 ·
メンテナーはふだん 2 日以内に返信