TRPC Forced to use nostore
Unanswered
Californian posted this in #help-forum
CalifornianOP
Taking a look at Create t3 app, it appears that utilizing TRPC from a RSC means that you are forced to flag the entire component with a
Are there any plans to address this? As marking all RSCs with
Alternatively is there a better way around accessing headers and cookies that might be used in replacement of the way t3 stack currently does?
no_store (due to it accessing headers or cookies) or else you end up receiving a build error that prevents auto deploys on Vercel but don't actually prevent the app from running when you start it locally.Are there any plans to address this? As marking all RSCs with
no_store feels like a bit of an anti pattern as simply leaving out the no_store breaks the build despite the app working fine.Alternatively is there a better way around accessing headers and cookies that might be used in replacement of the way t3 stack currently does?
19 Replies
@DirtyCajunRice | AppDir isnt trpc meant for live data?
CalifornianOP
not necessarily live, just for creating a type safe data layer
@Californian not necessarily live, just for creating a type safe data layer
im not sure what types have to do with headers 😅
sounds like that package trys to do too much
and may not be the answer for your use-case
CalifornianOP
seems to be an issue with anything that calls headers or cookies indirectly from within an RSC. TRPC and t3 are just popular enough packages that I would hoppe Next would address this issue because everything actually works fine, but Next decides to handle this by throwing errors on build despite the app working fine, and the errors break auto deploys
@DirtyCajunRice | AppDir im not sure what types have to do with headers 😅
CalifornianOP
when creating the endpoints it needs access to Next headers
@Californian seems to be an issue with anything that calls headers or cookies indirectly from within an RSC. TRPC and t3 are just popular enough packages that I would hoppe Next would address this issue because everything actually works fine, but Next decides to handle this by throwing errors on build despite the app working fine, and the errors break auto deploys
but... you can access headers and cookies in api requests.
its a package compatibility problem
not a nextjs problem
@DirtyCajunRice | AppDir its a package compatibility problem
CalifornianOP
and you can also access headers within an RSC where the TRPC api call is used
its not a matter of it not working... it works, TRPC gets the headers fine
its a matter of how Next decides to build
unless you do something like call cookies first within the top of your RSC and then again where you actually use it.... the error goes away. And that is definitely an anti pattern
easier than putting it in the route
@DirtyCajunRice | AppDir there is a function for that
CalifornianOP
Yes you can either use
no_store or cookies within your RSC and that gets the error to go away. But functionality wise they are not adding anything new because the app works fine without them, those functions in this situation are ONLY being used to bypass a Next.js build error and that is the anti-pattern I am trying to bring attention to@Californian Yes you can either use `no_store` or `cookies` within your RSC and that gets the error to go away. But functionality wise they are not adding anything new because the app works fine without them, those functions in this situation are ONLY being used to bypass a Next.js build error and that is the anti-pattern I am trying to bring attention to
If you view it as a bug, the right place to post that is github