16 Replies
why
why not
because most documentation is for app router
Did i hear unstable and unfit for prod
Tgats why
Close this
pnpm create [email protected]
App router betawhen i use this to create with all the things (including tRPC, NextAuth.js, and Prisma with the app router) after i login via the Discord provider callback it routes to
/profile. i don't get that when i use the stable version. any ideas?Read docs
i appreciate the simplicity of your response but would you mind sharing which docs and possibly providing a link?
i believe this is what you were referring to?? https://next-auth.js.org/configuration/callbacks#redirect-callback
Callbacks | NextAuth.js
Callbacks are asynchronous functions you can use to control what happens when an action is performed.
Just chime in, I decided to create a new project in NextJS app router with react server components
It would have been done a long time ago if I just went the pages route instead, the amount of weird app-router bugs that require way to much time to debug is way too large
very interested to hear more about those
The more I think about it, the more I think server actions is pretty much gonna kill trpc.
- server actions allows you to have type safety front and back.
- server actions can have loading state with the latest experimental useFormStatus
- server actions can have onSuccess and onError that you manually return from the server action via the experimental useFormStatus hook via the data you receive back from the server action
- In terms of middleware to validate sessions, you write a general server action to wrap another mutating server action
All in all... after trying to figure all that trpc stuff with the app router myself and not getting it to work on the server. IMO there's a reason why this is taking so long and the hype is dying around it a bit.
Cuz as I mentioned, when you get deeper into server actions, you realize you don't really need trpc imo
Edit: for anyone reading this, i wouldnt use server actions yet (sep 30 2023) cuz it’s still experimental and buggy namely with flashing of unstyled content. But just noting for the future of trpc vs server actions
@forehead 100%
Also feels weird starting a nextjs project with pages (or t3 stack) knowing the app router and server actions are the new thing. In some ways, glad that I never got fully invested into the t3 stack specifically BUT if t3 app router w/ trpc makes it out of beta it'll be interesting to see what happens
If create-t3-app adopts app router anytime soon, can we at least have a choice between app router and pages router until pages router is officially deprecated?
Maybe a noob question, but what would you suggest to use to replace trpc? I'm still working on my small project that is all T3 and future-proofing has been on my mind a lot
I’ve encountered a similar issue. Personally I would say be okay with rewriting your code. I used to think similarly to always want to futureproof but new things keep popping up and I keep getting outdated. I’d say just keep using what you’re familiar with and what you have working in your code. Then on your spare time learn the new things as it oftentimes helps you get a deeper understanding of how what you’re currently using works.
The difference between trpc and server actions and routes isn’t that much different per say, you can always port stuff over.
Overall I’d say keep doing what works and on your spare time you can dabble and learn.
For me personally, I used typical routes but it seems so clunky and slow and then I tried trpc but app router came out and I dropped it and when I tried to rewrite it I got it working but not for server calls and didn’t want to rewrite my backend to trpc and kinda gave up. Then lately I dove in server actions and it seems good but it keeps having issues with flashing of unstyled content. So now I’m back to using react query and GET/POST routes in the app router.
tl;dr just use what works and keep moving forward imo. Rewrites imo are kinda inevitable esp as you learn more things and new things keep popping up. One day you may switch your backend over to rust, so yeah just keep building and learning as you go and be okay with rewrites in the future
Also I want to take my statement back a bit. Server actions won’t kill trpc. But server actions really feels like a response to trpc and you can achieve many of the same things using server actions and fetch as opposed to trpc. So trpc is still fine. Keep using it if it works. But to me, it feels like server actions is the response to smth like trpc.
Also for anyone reading this: server actions is still experimental and has issues like flashing of unstyled content so I’m not saying we should adopt it now. But just that the future looks like server actions will be more of the default choice vs trpc.
Again, I’d avoid using server actions right now cuz it’s still buggy.
To add to your point about embracing the rewrite, I personally this tends to be the moment that I start considering how things are made swappable.
For example are you putting your server work in a separate function so that when you are done with the smallest possible responsibility in trpc (handling the validation and then calling out to your server function). On the react side of things I would consider how my components are interacting with trpc. Are they doing it directly or can you hand off to a custom hook.
This strategy might start to then mitigate some of the pain of refactoring to server actions at a later date since you’ve reduced your code’s exposure to the trpc dependency.