Correct tRPC implementation (NextJS AppDir)
Hello !
I'm a little bit lost on the tRPC examples, especially on "examples-next-app-dir"
When should I use this :
https://github.com/trpc/examples-next-app-dir/blob/main/src/trpc/server-http.ts
over this ?
https://github.com/trpc/examples-next-app-dir/blob/main/src/trpc/server-invoker.ts
and this ?
https://github.com/trpc/examples-next-app-dir/blob/main/src/trpc/rq-server.ts
GitHub
examples-next-app-dir/src/trpc/server-http.ts at main · trpc/exampl...
Contribute to trpc/examples-next-app-dir development by creating an account on GitHub.
GitHub
examples-next-app-dir/src/trpc/server-invoker.ts at main · trpc/exa...
Contribute to trpc/examples-next-app-dir development by creating an account on GitHub.
GitHub
examples-next-app-dir/src/trpc/rq-server.ts at main · trpc/examples...
Contribute to trpc/examples-next-app-dir development by creating an account on GitHub.
28 Replies
Hey @PavidR I'm in the exact same boat as you - curious if you made a decision/any progress since you posted this 12 hours ago?
I went with the T3 app implementation, using the hydration helpers from react-query/rsc package
But I’m still wondering how this work. I’m doing queries in RSC, but still experiencing loading times. I’ve seen no difference whatsoever between implementations
Let me know what you picked !
Awesome, thank you for sharing!
I can probably help with the loading times if you want to minimize or simulate it being instantaneous.
Curious - do you have to do a trpc server / client implementation? Meaning a separate procedure/instance if you want to use trpc to make requests on the server side vs client?
Yes, there are 2 different way to use tRPC depending if RSC/server or client
If I got your question right :kekw2:
Yeah that's my understand I guess just figuring out which pattern to use is the tricky part
for RSC/server there are 3 different ways ...That's...Confusing, not to say the least
What's confusing to me is in the pages router you'd have a
withTRPC
that wraps the app router / App itself
In app directory from what I understand is we create that kind of psuedo provider and combine it with a query provider to wrap the application and both of those use local state for the queryClient/trpcClientyeah that's it
I've never looked into the withTRPC hoc code
So i'm basically importing my
trpc
from /utils/trpc.ts then using that to make my requests however I have no clue how you would differentiate this from a server vs client (i'm using the createTRPCNext
method , does this handle if it's client vs server on it's own or did you by any chance go down the rabbit hole of setting up a createCallerFactory
? haha
I haven't even gone down the ssr/ssg options yet.
I have requests working I just feel it's pretty verbose on distinguishing which caller to use depending on server/clientHonestly all of this is so not documented that, you should trust maintainers implementations, like in T3
and be as flexible as possible
in case of API changes
agreed
yup
honestly, 50% of the time
I feel bad to use TRPC
Are you familiar with react query?
because I don't understand half of it
I get the broad picture, but not the fine details
For the loading times it sounds like it has to do with your refetchInterval/staleTime
If you are using the hydration pattern you can preFetch/PreHydrate your data as well and that can make it appear quicker
I think yeah, that's what I've to do
but its not really documented
I can help you out with that stuff if you want to have more granularity on when you are fetching/populating
Yeah I really recommend the ui.dev react query course, its a little expensive but it helped me out heaps
I display a list of questions, when clicking the question I'm redirected to a page where I display the single question
and the loading happens
the is doing the RSC tRPC call
and I pass down the initialData to my <Question /> component
and inside the Question component, I use the tRPC CLIENT stuff, passing initialData from props
so when I'm doing mutations etc, I benefit of the ReactQuery stuff, like optimistic UI etc
Yeah that sounds like a good pattern to use. Maybe think about if you want the fetch to occur on the parent level and then render the component conditionally or if you want to render the component
Another thing to note is that if you are using server actions that those can't run in parallel (you might want to double check to confirm) but I recall that being the case. So basically I try to stick to using server actions only for mutations
also keep in mind that RSC are different than a server action
nah I don't use server actions because I need every part of my API to be usable on a React Native app, later on 👍
oh great then hmm, im not sure why the load times would be exagerated with trpc
and I don't want to maintain : an API + bunch of server actions that do the same thing
if anything you should see some optimizations what with the batching/deduping and stuff that rq has out of the box for trpc to leverage
I mean, maybe the little loading times are normal/OK
is there a way to see the timeline of a RSC ? from call to render, times etc ?
This has been a big trip for me, its too easy for duplicate actions to exist.
It's too easy to fall into the pattern of creating a hook, to make a trpc call, to use a server action
Yup do you have the tanstack devtools installed?
If your layout/provider looks like this, you can add it in like so:
Yeah OK thanks, but that doesn't exist for RSC
but its late here in EU, gonna sleep and see this tomorrow !
thanks have a good one
well @Hobbs
I opted for prefetching in server components and leveraging
useSuspenseQuery
hook in client components + HydrateClient
does wonders, for nowHello,
Have you guys got any closer to a solution that combines a trpc provider and createTRPCNext? I gave up on ssr completely and used createTRPCReact but I am not sure... I mean if there is no ssr at all with createTRPCReact, why even use Next.js?
+