Tamás Soós
Explore posts from serversWhen error in tRPC route, the error message is vauge
That example with the console would just print undefined as it should, but if I do something like:
It gives me
Magic number procedure error
on the client side. I'm using this setup. It has no additional error formatting.12 replies
Would you recommend tRPC’s usage in this case?
I think there's nothing wrong with creating a reusable piece of logic, but you say make the client its own package. Why the client? Personally I'd create a private package with only the common logic in it as an async function. No reference to even trpc. Then I'd install this package on both applications, and invoke the library function in a procedure somewhere in a router.
This way you can easily:
- Transform the results further.
- Have completely unique trpc configurations.
- Have different trpc clients / links
- Use the api call anywhere, even without trpc.
- Extend the library with other API integrations in the future.
- Have independent repos for the two apps and the library without any issues.
7 replies
tRPC over WebSocket with Next.js and NextAuth
Yes, that's a nice starter. The type issue in their context file I was able to solve by only defining the type there, and using getServerSession in the api route vs getSession in the ws server. Still it would be nice to use getServerSession in both places.
I'll check out Lucia. The docs are nice. Thanks.
Since in the end this is more of a NextAuth issue, I asked them directly on github. I'll close this post.
9 replies
tRPC over WebSocket with Next.js and NextAuth
My issue is with the createContext call. The opts type isn't quite right. getSession is giving me:
even though it happens to be working for now. Btw getSession creates infinite reconnects on the ws client with any other inputs and getServerSession does the same except I couldn't find any arguments that work at all.
9 replies