Can I use the "Streaming with Server Components" strategy with tRPC?
https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#streaming-with-server-components
has a neat example on how to prefetch queries without having to await them. Is this something we can use with tRPC?
Advanced Server Rendering | TanStack Query React Docs
Welcome to the Advanced Server Rendering guide, where you will learn all about using React Query with streaming, Server Components and the Next.js app router.
You might want to read the Server Rendering & Hydration guide before this one as it teaches the basics for using React Query with SSR, and Performance & Request Waterfalls as well as Pre...
Solution:Jump to solution
GitHub
feat(react-query): next-app-router example with prefetch helpers by...
More integrated version of t3-oss/create-t3-turbo#877
adds a wrapped proxy around createCaller that puts the promise into a server-side QueryClient. devs can then choose to wrap some client compone...
47 Replies
Solution
GitHub
feat(react-query): next-app-router example with prefetch helpers by...
More integrated version of t3-oss/create-t3-turbo#877
adds a wrapped proxy around createCaller that puts the promise into a server-side QueryClient. devs can then choose to wrap some client compone...
Almost there - @julius is on it 🐐
GitHub
feat: hydrate.transformPromise by juliusmarminge · Pull Request #75...
Allows for deserialization of prefetched promises
That's awesome! Thank you!
Does this mean I don't have to use a SSRHelper to prefetch in a server component? Not too sure I understand the implications here
(for context why I have two dehydratedStates, I am using react-query and recently added tRPC)
I'm trying this and it at least seems to be working. However, I'm still seeing a fetch when using the example from the repo:
Is this intended? I thought it would stream with the initial request, no?
Is this on page load? If so that’s a bug.
But it should refetch from client as the data gets stale
Yes it is on a fresh page load. I have found rc.417 affected, but rc.403 (probably) working. See also:
https://discord.com/channels/867764511159091230/1253818679301242940
Ok I’ll take a look today and see what broke and add a better test, it seems to have slipped through this one https://github.com/trpc/trpc/blob/next/packages/tests/server/react/rsc-prefetch.test.tsx so might have to make an e2e test
GitHub
trpc/packages/tests/server/react/rsc-prefetch.test.tsx at next · tr...
🧙♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy. - trpc/trpc
hey @michaelschufi - I think the issue is related to data transforming and will require a fix upstreams in RQ
if you don't use data transformers i think it should work fine
Thanks for looking into it. 🙏
Hmm, data transorming is kind of really useful. I don't think there's a workaround, correct?
No there’s a race condition if the query finishes on the server before ”hitting the network” and then the query doesn’t get transformed on the client
Makes sense. Thanks for the explanation.
GitHub
fix: add
HydrateOptions.transformData to restore resolved prefetc...When a query gets resolved on the server before we dehydrate, the dehydrated query will contain the serialized data, but the transformPromise function will never run to deserialize it, leading to s...
(we'll probably deprecate/remove
transformPromise and have a generic transform for both data and promise)Hi Julius
I've tried this and updated the TanStack query library. However, I'm still experiencing the same behaviour.
The repro based on today's state of the trpc app dir example is here:
https://github.com/michaelschufi/trpc-next-app-dir-2
The significant changes I made:
https://github.com/michaelschufi/trpc-next-app-dir-2/commit/f7de44043d686b7fffad68ae23011edcc4fb1205
GitHub
GitHub - michaelschufi/trpc-next-app-dir-2
Contribute to michaelschufi/trpc-next-app-dir-2 development by creating an account on GitHub.
Yea the RQ change was only part of the problem. I have some fixes on trpc side too
I’ll try to find some time to finish it up and get it shipped soon
mmhkey I don't understand how this can even happen... will require more digging
cc @Alex / KATT 🐱 removing your "caching" does fixes the issue (added here https://github.com/trpc/trpc/pull/5810/files#diff-45606eb14a04e393dac5462656af6270472f51d2d81031b09ba0a57f537e2cd2). unsure what's going on here lol 🤨
i added that to make the hooks stable
we can revert it
i don't know why it doesn't work in RSC though....
the fact that it breaks something makes me anxious that i have cached something that shouldn't be cached
yea I think what's happening here is the path gets cached with no respect to the callback
so if you have multiple proxies it'll get fucked
oh damn
it can pick up a cached callback that's incorrect i think
let's revert the cache
we can reopen the og issue
doing now
ahve it here but you might wanna review that separately https://github.com/trpc/trpc/pull/5828/files
https://github.com/trpc/trpc/pull/5855
if the caching causes issues i wanna be safe and just revert it asap
if you have a regression of the issue you're facing, feel free to throw it into
packages/tests/server/react/regression/issue-5808-proxy-in-dep-array.test.tsx
then we can fix them both at the same time
caching the proxy was probably a bad idea in hindsightfair
i wonder how we can fix that original issue now
i guess i should not try at midnight though
going to bed, thanks for
@ing mei should too
i tried quickly to make a regression of what you reported here while reverting my revert, but couldn't make it to fail
https://github.com/trpc/trpc/pull/5856
ok, going to bed for real, ttyl
the prefetching works now atleast https://github.com/trpc/trpc/pull/5828
https://github.com/trpc/trpc/pull/5856/files#r1664895289
You guys are awesome. Looking forward to testing this out
This sounds great, thank you! I'll gladly test it.
bump to latest RC and you should have it
(not quite yet since our ci is failing on main right now due to some npm api changes)
rc.441 is out
Huh, interestingly, it still doesn't work with rc.441 (same code as before)
However, as soon as the page is exported as an async function (
export default function Home vs export default async function Home) it works. This happens in dev and prod mode.
I mean that there's an additional fetch request in the network tab.
something maybe offtopic: the trpc example now produces a hydration error because of toLocaleString on my machine. which makes sense, since the browser has a different locale configured. not sure if that's intended for such an exampleYou removed the ”shouldDehydrateQuery” extension
So you’re not dehydrating promises
GitHub
trpc/examples/.experimental/next-app-dir/src/trpc/shared.ts at next...
🧙♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy. - trpc/trpc
GitHub
trpc-next-app-dir-2/src/trpc/shared.ts at main · michaelschufi/trpc...
Contribute to michaelschufi/trpc-next-app-dir-2 development by creating an account on GitHub.
Ah, ok, yeah, this was breaking before with iirc
_def errors. I'll tryThis is essential to have RQ dehydrate and hydrate promises https://github.com/trpc/trpc/blob/525e2195c3d22c1dcdbec084f905d05af19f84e6/examples/.experimental/next-app-dir/src/trpc/shared.ts#L54
GitHub
trpc/examples/.experimental/next-app-dir/src/trpc/shared.ts at 525e...
🧙♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy. - trpc/trpc
Yea those are fixed now
Yep, looks good. It's working now 🎉 😀
This is sooo awesome!