-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documention/usage of withTRPCNext #53
Comments
Hi, apologies for the late answer! This is a documentation error. Here is the correct usage: // lib/trpc.ts
import type { AppRouter } from "@/server/_app";
import { createTRPCSWRNext } from "@trpc-swr/next";
import { httpBatchLink } from "@trpc/client";
export const api = createTRPCSWRNext<AppRouter>({
links: [
httpBatchLink({
url: "/api/trpc",
}),
],
})
// _app.tsx
import { api } from "@/lib/trpc"
export default api.withTRPC(MyApp) Lets leave this issue open until documentation is improved. |
Thank you for following up with this. I have one more question Can we create server side helpers without access to the router and context? According to the docs i need to create a ssr helper like this, which expects my context and router. export const createSSR = () => {
return createProxySSGHelpers({
ctx: {}, // my context expects req,res,db etc
router: trpcRoot,
})
} trpc has this docs for external routers. |
Its not possible with the SSG helpers unfortunately. SSG helpers are a wrapped version of router.createCaller. You can get away with not passing context though, but that depends on what you actually need in your context. What's your use case for not passing in router, req res etc? |
Yah and importing too. I have a fastify setup. Its a lil annoying to re-structure the router out of the backend module. Importing router directly causes nextjs to process the backend which is set up and bundled somewhat differently. So I'm immediately greeted by some errors. Having them separate has been really intuitive for me. Also useful for deploying them separetely. For example the nextapp to the edge and the backends to actual servers. Thank you for clarifying thou. I'll figure somth out |
I also keep mine separate, but very separate so I can drag the tRPC router into any framework. You need modify the tRPC context and create two context adapter functions, one for next and one for fastify. Then you need one unified context which is the context type you'll use for the router itself, both of the functions should produce the same unified context in the end. I definitely see the use case for this though. What you're asking for is the tRPC client to run on the server over http instead of Its definitely doable! |
My bad lol misclick. Thank you for the sugestion and yah this feature would indeed be helpful for users. My suggestion would be to keep it in the roadmap, if this gets enough attention one day, this would be a worthwhile implemention. |
#54 Is in canary right now with some changes for Next 14 AppDir. Going to improve docs and refactor some more pages dir related code this week. |
The import is renamed to
withTRPCNext
. ThewithTRPCNext
function expects 2 arguments, and both of them cannot be empty apparently.The following line throws the error
I tried passing the trpc config like below. But it still expects more the second argument to be fullfilled
I'm not quite sure what to pass here. A hint would helpful. Heres my package versions.
The text was updated successfully, but these errors were encountered: