Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

solid-query v6: useQueries doesn't attach to the new hydration channel from #11168

オープン
#11,185 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
frontend, web-dev

調査の方向性

packages/solid-query/src/useQueries.ts と #11168 の hydration-channel の変更から始め、useQueries と useBaseQuery について説明されている priming パスを比較します。SSR/hydration の fixture である hydration.test.tsx を実行します。ストリーミングされたデータの priming 中に mount refetch を発生させず、useQueries が provider 所有の channel と連携できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

#11168 (merged today on solid-query-v6-pre, targeting @tanstack/[email protected]) adds a provider-owned hydration channel so QueryClientProvider primes the cache from the server-dehydrated stream and useBaseQuery waits for its own entry to be primed (whenQueryPrimed) before attaching its observer, instead of doing a mount refetch on data that's about to arrive.

useQueries doesn't go through any of that. I read the current packages/solid-query/src/useQueries.ts on solid-query-v6-pre: it builds its own QueriesObserver directly —

const observer = untrack(
  () => new QueriesObserver<TCombinedResult>(client(), defaultedQueries(), ...),
)
...
createEffect(() => {
  if (!isRestoring()) {
    unsubscribe = observer.subscribe((result) => { ... })
  }
})

— with no reference to hydrationChannel, whenQueryPrimed, or the executorRan replay-detection flag useBaseQuery added (confirmed with rg "whenQueryPrimed|executorRan|hydrat" over the file: zero matches). The observer is constructed and its optimistic result read synchronously on mount, so if this runs before the provider's channel has applied hydrate() for these query keys, useQueries sees a cold cache and behaves exactly like the pre-#11168 useBaseQuery did: no priming coordination, so a query whose data is already in flight from the SSR stream can still trigger a mount refetch even though it's well within staleTime.

This isn't a guess — the PR body says so explicitly under "Coexistence with TanStack Start": "useQueries does not go through this path (it did not serialize hydration data before either); with the channel in place its queries would be primed too as soon as they settle on the server — client attach for it could be covered in a follow-up."

Since this is still pre-release (solid-query-v6-pre, not yet on main), flagging it now while the hydration channel work is fresh in mind seems more useful than after the branch merges and beta ships. Happy to help verify a fix against the same hydration.test.tsx SSR/hydration fixture #11168 added if that's useful.

主要言語
TypeScript
スター
50.4k
フォーク
4.2k
平均マージ
7時間 37分
マージ済み PR(30日)
420

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/query のほかの issue

TanStack/query の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。