feat(react-query): next-app-router example with prefetch helpers #5451
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Diagnostics ComparisonNumbers
Timings and averages
unstable timingsUnstable
|
| <UserButton /> | ||
| </div> | ||
| </Suspense> | ||
| <HydrateClient> |
There was a problem hiding this comment.
good that this is contextual
if you have many of these, i guess they keep on sending stuff doubly? it would stack up quite a lot of it was used a lot
maybe we could keep track of stuff that's already been sent to the client so we don't send same query times across many hydration boundaries
There was a problem hiding this comment.
if you have many of these, i guess they keep on sending stuff doubly? it would stack up quite a lot of it was used a lot
i would actually have thought RQ would handle this internally. isn't this an issue no matter where you use them?
There was a problem hiding this comment.
cc @TkDodo - do you handle deduping?
There was a problem hiding this comment.
there is no deduplication with HydrationBoundary. Every boundary will send its content to the client.
@Ephem we talked about this some time ago I think ?
There was a problem hiding this comment.
I think there is if you use the same queryClient maybe ?
There was a problem hiding this comment.
it should be a single query client per request https://github.com/trpc/trpc/pull/5451/files#diff-8ef8de9fb13401a32e846aeaedf32d659dd5f222706751573fb792d04d36e66cR24
There was a problem hiding this comment.
I think we've moved away from this recommendation precisely because of this:
In the example above, we create a new queryClient for each Server Component that fetches data. This is the recommended approach, but if you want to, you can alternatively create a single one that is reused across all Server Components:
also:
As a future improvement, we might look into creating a dehydrateNew() function (name pending) that only dehydrate queries that are new since the last call to dehydrateNew(). Feel free to get in touch if this sounds interesting and like something you want to help out with!
Is this you getting in touch to implement that feature 😅 ?
There was a problem hiding this comment.
Ah yeah, I forgot I used ye old "document the flaw and hope someone fixes it" approach here.. 😂
To be clear, it never dedupes, no matter if it's one queryClient or not. Compression does remove some of the overhead, but I think less than usual when streaming. Implementing dehydrateNew seems relatively straightforward on the surface, but I'm not sure if there are any hidden footguns or edge cases. 🤷
|
This is great. Having to manually pass around initialData to client components, or doing manual prefetching and dehydration does feel very repetitive. Hope this can be merged soon. |
|
Would love to have this feature as well, it would save me so much time ❤️ |
More integrated version of t3-oss/create-t3-turbo#877
adds a wrapped proxy around createCaller that sets data to a server-side QueryClient. devs can then choose to wrap some client component that needs some server prefetched data with the
<HydrateClient>component. no network requests will be made from client components until the prefetched data goes stale:https://utfs.io/f/8278fdc7-572e-4b14-9f10-5f9fece747bb-yl67w4.15.58.mp4
Also got a
<PrefetchQuery query={}>HOC if you just wanna prefetch data in RSC without using said data in it. This makes for easier composition since you wouldn't need to create new components just to await the query in it, if you don't wanna block all the way up (if that makes sense)This gives the same behavior as the
ReactQueryStreamedProvider, but you can do authed procedures since there's no fetching in client componetns, even on the server, so no need to hack the RSC headers into the CC which causes some weird security concernsCleanShot.2024-03-07.at.23.03.56.mp4