Public per-session initial-load signal on collections (adapter read gates)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 55/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- data
調査の方向性
collection-options スコープと collection のプライベートな _lifecycle state から始め、既存の snapshot-commit と sync-start のパスを追跡します。完了の条件は、collection が公開されたセッション単位の boolean と subscription を公開し、sync-start でそれらをリセットし、最初の sync-commit 後にそれらを設定し、adapters が重複した flag を削除できるようにすることです。
索引モデルが issue の本文から書いたものです。
説明
Outcome
A public, per-session "initial load complete" signal on the collection: a boolean plus a subscription, reset when a sync session starts, set when the session's first sync commit lands. Sync adapters could then delete the equivalent flag they each maintain, and useLiveQuery consumers could tell "ready because this session loaded data" apart from "ready because of a seed or a revival".
Why the existing signals do not cover it
Our adapter falls back to a cached snapshot until the collection has loaded in the current sync session. The public signals answer a different question:
collection.isReady()andstatus: 'ready'describe the collection's lifetime. They stay true after a GC-and-revive cycle, although the revived instance's data was cleared. They also stay true when a load fails after an earlier success. A read gate built on them serves an empty or stale collection instead of the healthy fallback.hasBeenReadyis per-session but private (collection._lifecycle) and has the same revival behavior.
What we do today
We keep a boolean in the collection-options scope: set on snapshot commit, reset on every sync start, exposed through collection.utils with a subscribe. It works, but it duplicates state the library already tracks.
- 主要言語
- TypeScript
- スター
- 3.9k
- フォーク
- 272
- 平均マージ
- 1日 1時間
- マージ済み PR（30日）
- 222
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
TanStack/db のほかの issue
-
Electric progressive: apply and confirm changes to visible rows during the background full syncオープン
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
メンテナーはふだん 1 日以内に返信
-
Extend the Effect skipInitial oracle lane: ordered windows, includes, failures, and ordinary Effectsオープン
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
メンテナーはふだん 1 日以内に返信
-
Progressive collection live queries remain suspended after their requested subset finishes loading対応中かも @KyleAMathews が今日担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 5/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
bug help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
agent-task risk:low
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
guyellis/http-status-check#512 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
microsoft/playwright#43327 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
microsoft/TypeScript#64758 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
opensearch-project/OpenSearch-Dashboards#12937 ·
メンテナーはふだん 2 日以内に返信