denik1981
When using createServerSideHelpers can the context be typed as GetServerSidePropsContext?
I assume the reason we should recreate the context when using createServerSideHelpers is because the req, res we get from GetServerSidePropsContext are not typed the same as the ones we get from NextApiRequest and NextApiResponse.
Fair enough. but can I create create my context based on the ctx we get from GetServerSidePropsContext?
If that the case is it a good approach to extend the InnerContext from the union of the both Partial contexts, and by "both" I mean the context we are expected to get and work with when calling our routers from the next API handler and from getServerSideProps?
Sorry if my question is not very clear and probably the answer won't be needed by me because I'm trying to not use getServerSideProps at all but still I would like to master my understanding of how TRPC serverSideHelpers are doing this in case I need them in the future.
The goal here will be to keep procedures that depend in certain values obtain from req or res being able to work dispite the source of the caller. So I would expect to regenerate the context for my instance of serverSideHelpers properly to make the request pass and being processed without troubles.
Thanks!
2 replies
Is it ok to use a createCaller() router within ServerSideProps?
The official trpc docs shown an example of how to use the SSGHelper router within SSPs. The procedure I wanna use needs the session object within the context. This procedure is shared by the public API trpc router thus I wouldn't want to create a different procedure that will do the same but taking the session information from someplace else.
I was able to create a server side only router with createCaller and tne innerContext as suggested and it is working perfectly inside SSPs.
Is there any CAVEAT regarding using this type of reouter instead the SSG provided. I do understand that I won't be able to prefetch and hydrate the page, but apart from that, is there anything that I should be aware of.
My particular use case was not feeding props into the page but to get a value from the user procedure that wil later allow to redirect to another path. This is working great with the SSO router but I'm planning to use it later for a traditional SSP props feed operation.
2 replies