Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#11,185 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
frontend, web-dev

Rechercherichtung

Beginnen Sie mit packages/solid-query/src/useQueries.ts und den Hydration-Channel-Änderungen aus #11168 und vergleichen Sie useQueries mit dem für useBaseQuery beschriebenen Priming-Pfad. Führen Sie das SSR/Hydration-Fixture hydration.test.tsx aus; abgeschlossen ist die Aufgabe, wenn useQueries mit dem vom Provider verwalteten Channel koordiniert wird, ohne einen Refetch beim Mount auszulösen, während gestreamte Daten vorbereitet werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

#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.

Vorherrschende Sprache
TypeScript
Sterne
50.4k
Forks
4.2k
Ø Merge
8 Std. 37 Min.
Gemergte PRs (30 T.)
417

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/query

Alle Issues in TanStack/query

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.