We are experimenting with the app dir and will support it at some point, but certainly not while it is still experimental/unstable. See the "bleed responsibly" section of our axioms - we want to provide users with a stable, production ready way of building an app now.

In the meantime it's fairly easy to implement yourself, but there are a few remaining footguns related to invalidation across the network boundary, waterfalls, etc. We will hopefully find out soon what Next.js has planned for mutations/actions.

https://create.t3.gg/en/faq#why-are-we-using-pages-and-not-app-from-nextjs-13

@c-ehrlich you guys are working on this feat, right?

Why not add this as an optional flag in the CLI? Even Theo has talked about hating use of the old patterns lol. Also from anecdotal experience I know people that bootstrap their application with create-next-app instead of t3 solely because they can't take advantage of the app directory, so having an option to opt-in to the app directory-based pattern seems to me like it would help increase adoption.

Heavily waiting for it to be able to use https://beta.nextjs.org/docs/routing/parallel-routes with tRPC easily. Instagram-like routing seems to not be possible with Next.JS 13 and without appDir ;(

Hello! Now that it is stable, are we planning to work on this?

It's stable now guys, let's gooo

Let's go?

The time has come 💯

Next.js 13.4 is a foundational release, marking stability for the App Router:

App Router (Stable):

• React Server Components
• Nested Routes & Layouts
• Simplified Data Fetching
• Streaming & Suspense
• Built-in SEO Support

https://nextjs.org/blog/next-13-4

I think the biggest concern with regards to this is how tRPC should be handled, since not even tRPC has yet official support for Next App Directory and React Server Components.

Should we just wait for tRPC to first implement a "official" solution to tRPC with App Dir and RSC, or just build own workarounds for using tRPC on Server Components and Client Components?

Context for discussion is available here.

EDIT: Created a quick version of create-t3-app for App Dir, and even though I got tRPC working with workarounds, NextAuth also needs workarounds... Maybe focus should be to get these upstream packages first to support App Dir?

It will be at least a few weeks before we support the app router. Maybe longer. The real ETA is "when we can ship something that feels good enough".

Making a CLI that initiates a project with the app dir is trivial - create-next-app already exists and has gotten really good in recent months. If all you want is a Next.js app that uses the app dir, you should use that, it's great!

But please consider:

• We need to wait on some stuff from upstream packages, and figure out what their place is in this new paradigm
• Create T3 App is about opinions / "best practices", and we need to first figure out what those are
• There are some footguns currently. One example: https://twitter.com/tomus_sherman/status/1654211227172716545
• Now might be a good time to move from lambda to edge, and that requires more considerations

Obviously app dir is where the ball is rolling and I can understand that initing a project on pages dir now feels bad. But thousands of projects get create with CT3A every week, so we have some amount of responsibility to get it right from the start. We'd rather be a bit late to the party if that's what it takes.

I don't want to get too off-topic in this issue, but I'm curious about the role tRPC will serve with the introduction of RSC. If I need to access the DB or filesystem, is there a reason I wouldn't put that logic into a RSC?

I suppose any data mutation triggered by user action in a client component is still a good use case for tRPC... at least until Server Actions become stable. Anything else?

@ealexhaywood was having similar thoughts. Still trying to get the right mental model for trpc with the introduction of server components, as it still seems confusing. Down the line when server actions are stable (could be ages away), will trpc even be required?

@ealexhaywood was having similar thoughts. Still trying to get the right mental model for trpc with the introduction of server components, as it still seems confusing. Down the line when server actions are stable (could be ages away), will trpc even be required?

I think tRPC will continue to be useful, as it defines many things on the server and client that makes it easier to work with Nextjs, giving you full typesafety. What may be removed is Tanstack Query, since it seems that Nextjs is going to take care of managing the client/server cache.

Hey guys: I think @juliusmarminge is working on this: https://github.com/juliusmarminge/t3-app

Hey guys: I think @juliusmarminge is working on this: https://github.com/juliusmarminge/t3-app

As i check the repo, they simply make everything client side so it can compatible with current tRPC version, and it is not optimal at all since it kills most benefits of appDir.
As @c-ehrlich mentioned, we need to wait for tRPC team to make an brand new user story for this, which could takes months. For now let just try what NextJs provide us and use them.

As i check the repo, they simply make everything client side

There is no client side fetching in that repo...

As i check the repo, they simply make everything client side

There is no client side fetching in that repo...

not sure but as i check this file it has "use client" in it, and the component wrap the whole app, so ...

Yea but thats not how RSC works - you can interleave server and client components through compostion - just dont pass them as props.

Read up a bit on the RSC model- the nextjs docs have some and i believe @c-ehrlich has a good video too 👍

@juliusmarminge Is the usage of tRPC from the server action only for validation / middleware authentication stuff? If the server actions were more stable in the future would you replace tRPC with something like zact?

@juliusmarminge Is the usage of tRPC from the server action only for validation / middleware authentication stuff? If the server actions were more stable in the future would you replace tRPC with something like zact?

That's a hypothetical question that's difficult to answer for the time being. Server actions are in an early state, tRPC invalidating across boundaries is in an early state, and zact is in an early state.

If you're building with this stuff currently, you need to be ok with the fact that you might commit to something that doesn't end up being the popular solution.

I don't want to get too off-topic in this issue, but I'm curious about the role tRPC will serve with the introduction of RSC. If I need to access the DB or filesystem, is there a reason I wouldn't put that logic into a RSC?

I use tRPC in Next.js with trpc-openapi so I can expose endpoints with the same functionality as a REST API. Maybe RSC will make its way as the default for data fetching for components in Next.js but then I have to create a separate API for REST calls. Because of that I am more likely to stick with tRPC.

Has anyone created a template or repo of T3 app with next.js app dir (stable)?

Has anyone created a template or repo of T3 app with next.js app dir (stable)?

Not that I know but Julius created a new repo with the app router: https://github.com/juliusmarminge/acme-corp

Has anyone created a template or repo of T3 app with next.js app dir (stable)?

Hey guys: I think @juliusmarminge is working on this: https://github.com/juliusmarminge/t3-app

That one is probably the most 1-1 port rn - but it's not the best dx when it comes to client side fetching etc. That's what we're figuring out still...

Obviously app dir is where the ball is rolling and initing a project on pages dir now feels bad. But thousands of projects get create with CT3A every week, so we have some amount of responsibility to get it right from the start. We'd rather be a bit late to the party if that's what it takes.

Is it really that bad to initialize a project with the pages dir still? Next.js will continue to support the pages router for a while, but it seems wrong to think that it's bad practice to use it. I love the T3 stack because of how fast I can spin up an idea and get it working as a solo dev. I know the app dir came a bit earlier than expected and is now stable, but I've run into quite a few libraries that don't support it without a workaround yet (tRPC in T3's case).

I've used the new app dir and I gotta admit, it's pretty awesome. But is there any reason why I should use it over the pages router while we are in this transition phase?

Looks like an app dir install experimental option will be easier to deploy now https://github.com/trpc/examples-next-app-dir

You can follow #1446 - I'll publish beta releases from there which have experimental app router option. This is the latest one:

pnpm create [email protected]

This is probably not the write place to post this question but what happens when Server Action is available? Does that mean maybe t3-create-app will provide options for backend API?

While the stable is using pagesDir, I think the t3-app can have beta things like next.js does for any experimental stuff like these, so the community get hyped more 🤣 🚀

But the developer should opt-in, not by default. I found out the appdir branch uses unstable serveraction, and it's great to play with these stuff 👍

Note that regardless of whether you're using server actions, React Server Components are also unstable.

While the stable is using pagesDir, I think the t3-app can have beta things like next.js does for any experimental stuff like these, so the community get hyped more 🤣 🚀

But the developer should opt-in, not by default. I found out the appdir branch uses unstable serveraction, and it's great to play with these stuff 👍

stable is using app directory now

While the stable is using pagesDir, I think the t3-app can have beta things like next.js does for any experimental stuff like these, so the community get hyped more 🤣 🚀
But the developer should opt-in, not by default. I found out the appdir branch uses unstable serveraction, and it's great to play with these stuff 👍

stable is using app directory now

The t3 app cli or nextjs?

While the stable is using pagesDir, I think the t3-app can have beta things like next.js does for any experimental stuff like these, so the community get hyped more 🤣 🚀
But the developer should opt-in, not by default. I found out the appdir branch uses unstable serveraction, and it's great to play with these stuff 👍

stable is using app directory now

The t3 app cli or nextjs?

Nextjs.
Nice username btw.

@juliusmarminge Why the latest beta channel only have drizzle, but not having appDir option?

@juliusmarminge Why the latest beta channel only have drizzle, but not having appDir option?

Cause i want to keep them as separate concerns, otherwise it would be very hard to review if both PRs were squashed into 1.

Hopefully the Drizzle one can get merged soon though and then we'll get that option in here too

@juliusmarminge I'm testing the appdir, how can we revalidate while using serverAction?

Let's say I fetch all postsawait api.post.getAll.query() then I add new post using serverAction, it'll not update the getAll automatically.

@juliusmarminge I'm testing the appdir, how can we revalidate while using serverAction?

Let's say I fetch all postsawait api.post.getAll.query() then I add new post using serverAction, it'll not update the getAll automatically.

https://github.com/trpc/trpc/blob/main/examples/.experimental/next-app-dir/src/app/post-example/page.tsx

+1

Is it coming out anytime soon?

Hello guys, I found a video by Jack Herrington, that makes trpc works with NextJS, check it out here video

Hello guys, I found a video by Jack Herrington, that makes trpc works with NextJS, check it out here video

I used exactly this and it seems to work fine :)

I still don't understand, why is the appdir-smaller branch using createTRPCProxyClint instead of useCaller? @Konadu-Akwasi-Akuoko

@dBianchii createTRPCProxyClient is used to create a client for your API, useCaller is used to access this client within your React components

I had to pass up on t3 for a project at work because they are still using the pages dir. Also swr is better than react query.

https://github.com/t3-oss/create-t3-app/releases/tag/create-t3-app%407.22.0