RFC: Layouts #37136
Replies: 165 comments 315 replies
-
|
First of all, this was fantastically written and presented. It provided adequate context without being overly verbose or complex and the example images are great. At the risk of bike shedding, I'm not sure that the |
Beta Was this translation helpful? Give feedback.
-
|
IDEs already have a solution to the problem of when you have the same file name multiple times On vscode, when you use ctrl + p is possible to also specify the folder to be searched, so instead of just searching for "layout" you can type "dashboard/layout" and it will be much more assertive
About the convention I think it would be even better if both patterns (*.layout.js or layout.js) are supported and is up to the developers to define which one they prefer. |
Beta Was this translation helpful? Give feedback.
-
|
There are some more cases where the same name might cause a slightly worse dx: Error Traces: React Dev Tools: Tabs (e.g. Stackblitz): |
Beta Was this translation helpful? Give feedback.
-
|
We can make the DevTools show the folder name to handle these cases. I think we already do that for files called |
Beta Was this translation helpful? Give feedback.
-
|
also |
Beta Was this translation helpful? Give feedback.
-
|
@jon64digital Why would looking at the parent folder name instead of the filename be so hard for you? You’ll have to look at the ancestor folder names anyways if you have several dashboards / settings in different routes to figure out which of them you are looking at. VSCode should show the path in the search field and the breadcrumb of the editor too, so you’ll just have to move your eyes one slash to the left. As for why, I think the post shows the advantages of using folder names over file names very well. |
Beta Was this translation helpful? Give feedback.
-
|
As mentioned by @baiirun , this is really well written and presented and the drawings are perfect for a good comprehension about the changes. Is there a reason to not keep the naming conventions with prefixed |
Beta Was this translation helpful? Give feedback.
-
|
I think it also makes sense when considering dynamic routes. |
Beta Was this translation helpful? Give feedback.
-
|
💪 I think _layout.js is a good idea, just like _middleware.js, without changing current behavior! this will reduce number of directory in a project. |
Beta Was this translation helpful? Give feedback.
-
|
Easier migration is nice and important, but the easiest migration is when nothing changes and you stay in same system, so you also need to ask whether being able to maintain the names (mostly) is worth not taking the benefits of changing it. I was about to propose naming |
Beta Was this translation helpful? Give feedback.
-
|
another like next.js framework UmiJS nested layout, very good, because it contains too much of its own ecology, the new project does not want to continue to use. so I hope next.js improve self nested layout as soon as possible. |
Beta Was this translation helpful? Give feedback.
-
|
I think that ability to co-locate page/route files near each other is more important than easier migration, or fewer folders... One of the most annoying things in the current version of next is just that. The proposed solution is great in my opinion, I would stick to that. |
Beta Was this translation helpful? Give feedback.
-
|
The answer to this is almost definitely a "yes", but just to confirm: I assume that anywhere it references a name like |
Beta Was this translation helpful? Give feedback.
-
|
Yes! |
Beta Was this translation helpful? Give feedback.
-
@leerob I think this line needs to be reworded to clarify that the filename needs to be 'page' and the extension can be any valid Next.js extension. Current wording suggests only |
Beta Was this translation helpful? Give feedback.
-
|
Great point, I will fix this. |
Beta Was this translation helpful? Give feedback.
-
|
IMHO the wording should reflect the current |
Beta Was this translation helpful? Give feedback.
-
|
This looks incredible. Will |
Beta Was this translation helpful? Give feedback.
-
|
Presumably the same way you can already do that today with index.js: |
Beta Was this translation helpful? Give feedback.
-
|
As @k15a said dynamic segments will still be supported as directory names |
Beta Was this translation helpful? Give feedback.
-
|
In the case where the optional catch-all is the only route, this new syntax seems harder to use. We designed a multi-page component that developers mount on /sign-in/*. It mounts a bunch of routes on their behalf:
Currently, we ask developers to mount our component in pages/sign-in/[[...index]].jsx If I understand correctly, now we'll need to ask developers to mount in pages/sign-in/[[...segments]]/page.jsx The extra directory is an unfortunate extra step, and this syntax is quite verbose to define a wildcard route. |
Beta Was this translation helpful? Give feedback.
-
|
There are multiple reasons for having directories instead of any file is a page.
|
Beta Was this translation helpful? Give feedback.
-
|
Okay - will the presence of an optional catch-all directory remove the requirement for a The directory structure may lend itself to removing the "optional" catch-all concept:
Do most developers want an extra layer of layout/loading/colocation for their catchall routes? If not, a |
Beta Was this translation helpful? Give feedback.
-
|
First of all, congratulations on the proposal. I believe this will greatly improve responsiveness and the developer experience. That being said, I have a few questions:
Again, great work! |
Beta Was this translation helpful? Give feedback.
-
Note there's an alternative convention being discussed in reactjs/rfcs#189 (comment), which is linked from the post. It is possible the RFC will be updated to it. |
Beta Was this translation helpful? Give feedback.
-
Could you expand on what you mean exactly, it's unclear to me what you mean with regards to rendering layouts per depth of params.
The second post will go into the modal case with examples 👍 Basically you'll be able to have a route rendered differently on client navigation (e.g. to open a modal). |
Beta Was this translation helpful? Give feedback.
-
Reading back my own question is sounds a bit stupid since multiple params would still only match a single route, which would imply that a single layout would be rendered, but thats what I wanted to confirm. When a url like |
Beta Was this translation helpful? Give feedback.
-
Yeah if you have <DashboardUsersLayout>
<ParamPage /> {/* When navigating between /dashboard/users/tim and /dashboard/users/bruno only `ParamPage` is rendered `/ */}
</DashboardUsersLayout> |
Beta Was this translation helpful? Give feedback.
-
|
Great job on the RFC and this is very exciting! One thing jumps out as a potential pain-point with the naming convention here. If one of the stated benefits that this enables is colocating code with your routes, I foresee many applications with hundreds of files named Would it be possible to allow engineers to define layout vs page by filename pattern? ie)
|
Beta Was this translation helpful? Give feedback.
-
|
This was my first thought when I saw |
Beta Was this translation helpful? Give feedback.
-
|
I agree with this 100%. It's my main complaint about the |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the proposal but want to share a trick I always used with Next.js: Symbols in VS Code. Screenshots: https://twitter.com/BennettDams/status/1529051702351085568 |
Beta Was this translation helpful? Give feedback.
-
|
Folder names are already part of a route. In a sufficiently big app the last segment may not be sufficient or unique to tell you where you are, so you already need to look at the parent folder name. This proposal just makes this consistent. As for editors, they already provide support for showing the ancestor folder in search and usually in the editor as breadcrumbs. VSCode also allows to show it in the title. |
Beta Was this translation helpful? Give feedback.
-
|
Congratulations on the really well written posts. But can we talk about the naming of page.js/tsx? Edit: another question that came into my mind: how would you change layouts based on a user prop? Let's say the user is a paid member or admin or moderator? With this new RFC, would you need to implement the differences on all layout.tsx files? |
Beta Was this translation helpful? Give feedback.
-
|
I think I would prefer this:
Besides text editor concerns, I prefer an optional One thing that worries me, though, is that text editors often group directories and files separately. I'm not sure if that's more or less painful than a lot of files with the same name. Edit: I believe it would resolve the concern from @baiirun above that pages are not actually pages |
Beta Was this translation helpful? Give feedback.
-
|
Yes imo the "_" convention or any other convention is necessary, first it put the page on top for alphabetical order, which is great, then it avoids confusion when "Page" or "Layout" are actually meaningful things in your business domain, which is pretty common |
Beta Was this translation helpful? Give feedback.
-
|
Is getInitialProps still supported with layout.js? Otherwise it could become a bit of an hassle maintaining a clientside GraphQL cache (as mentioned here #19611) I know GraphQL is not first-class, but the same issue exists for any request that can be skipped and until now this was one of the reasons why Next.js was the only reasonable choice for GraphQL APIs. This obviously contradicts with the direction towards server components but there's still a lot of merit for shipping the bundles to the client and having an simple stateless backend after the first render and the "rendering runtime" on the client (offloading future work) |
Beta Was this translation helpful? Give feedback.
-
|
I get the sense that they are trying to avoid wrapped apps like with Apollo. |
Beta Was this translation helpful? Give feedback.
-
|
In Next.js, we'll probably support getInitialProps for backwards compat. We are also separately considering the use case of "seeding" data from the server during SSR but not during client navigations. In React, we're also considering these use cases when adding additional support for serializing data through the HTML stream. See reactjs/rfcs#219 for a start of the discussions. |
Beta Was this translation helpful? Give feedback.
-
This in particular is really exciting. It's a problem I've been poking at a lot with SWR and haven't really come up with a satisfactory solution. |
Beta Was this translation helpful? Give feedback.
-
|
According to the RFC, "by default, files inside app will be rendered on the server as React Server Components". And in server components we will be able to directly fetch data and interact with a db or any external API directly from the React code (as showcased in the original RSC demo with the react-pg or react-fs example libraries). However, instead of fetching data in the component itself (either a layout or a page), in the RFC it looks like the recommendation would still be to use getServerSideProps as in the current SSR pages. Would there be a difference between choosing one method or the other? Will the "use server code directly in React" be discouraged in Next? If we choose to directly call server code in React, how can we tell Next that it should or shouldn't make it a static route? Will the server code defined in the component be able to run statically too (without using getStaticProps)? If we call server code in the component level, can we still share it with parent/children segment layouts? Will there be a route context or similar that can be used to read/refresh data from any part of the tree (including a client component)? I definitely see a window for database providers and APIs publish React utilities either in the form of hooks (like Hydrogen's useShopQuery) or components (like the experimental proof of concept from prisma). At this early stage and without having read the second post yet, it looks like building this kind of tooling on top of React RSC will probably be limited and adoption reduced if getServerSideProps/getStaticProps are still the recommended way of providing data to a route. Note: Before reading the RFC I had naively thought that getServerSideProps would be deprecated in favor of data fetching in RSC, so I might be a little biased against it with my "how would I do it" expectations. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also curious about this. Will we be able to fetch at the component level? |
Beta Was this translation helpful? Give feedback.
-
|
Longer-term both approaches will be supported but currently Suspense for data fetching is not stable yet and not specifically tied to React Server Components, getting to the result where components are rendered server-side while data fetching happens in getServerSideProps/getStaticProps will be the intermediate state and longer term both will be supported. The main benefit for fetching data outside of the component tree currently is that it does not create a render-fetch-render-fetch waterfall which is explained in this part of the RFC: https://nextjs.org/blog/layouts-rfc#parallel-fetching-and-rendering The data fetching will be kicked off eagerly regardless of rendering as we know what layouts / page will be rendered before the React rendering starts. This diagram from the blogpost explains it visually:
The simplest demo of this would be: // app/dashboard/layout.js
export async function getServerSideProps() {
// Simulate intentionally slow data fetching by 5 seconds
await new Promise((resolve) => {
setTimeout(resolve, 5000)
})
return {
message: 'Dashboard'
}
}
export default function Layout({message, children}) {
return <>
<h1>{message}</h1>
{children}
</>
}
// app/dashboard/teams/page.js
export async function getServerSideProps() {
// Simulate intentionally slow data fetching by 2 seconds
await new Promise((resolve) => {
setTimeout(resolve, 2000)
})
return {
message: 'Hello to the teams page'
}
}
export default function Page({message}) {
return <>
<p>{message}</p>
</>
}With this example If you were to fetch data during rendering of As you can see the timing would grow as you add more data fetching, if you had another layout that took 3 seconds and then another that took 4 seconds you'd end up taking a total of 14 seconds compared to 5 seconds when the run in parallel. Note: I'm intentionally using large numbers to clearly show the difference, in practice these numbers will be x milliseconds but as shown it's would stack up in a similar way. |
Beta Was this translation helpful? Give feedback.
-
What about a case where I want the settings page to have a different layout from the rootlayout. Like having a separate Dashboard Layout for |
Beta Was this translation helpful? Give feedback.
-
This is already possible today with Apollo or Relay. However for all projects without GraphQl the RFC improves (and simplifies) many data loading performance issues quite elegantly. I have one further question for data loading: How would you recommend to solve recurring data waterfalls? E.g.: inside nested layouts and inside the content you want to load and display additional data only if the user has the administrator role. |
Beta Was this translation helpful? Give feedback.
-
|
You need the request object for personalization of the server render. I think React Server Components don't have access to the HTTP request, but Next can pass it via getServerSideProps. Since server-render happens in a "safe-space", where we can fully trust the props object to be sanitized and secured (think passing the current authenticated user for instance), isn't there a risk of confusion when we leave this sanitized world? |
Beta Was this translation helpful? Give feedback.
-
|
Great article. Did not see any information about error boundary and using layouts to restrict errors. |
Beta Was this translation helpful? Give feedback.
-
|
I'm assuming this would be documented in the next RFC that talks about how the framework will use Suspense behind the scenes. Hopefully an example would be included there. |
Beta Was this translation helpful? Give feedback.
-
|
We'll be covering this in part two 👍 |
Beta Was this translation helpful? Give feedback.
-
|
How committed are we to the In Nx monorepos, Next.js apps are already within an If you replace the usages of
vs
and
vs
These new files are lifting away from the Pages paradigm to be backwards compatible, but they are still responsible for routing (and "routing" is a common naming concept of React in general). Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @ervwalter, and want to add a use case that might hinder backwards compatibility that’s being thought of in the RFC. I can think of a few projects I’ve seen in recent past that already have an Making it configurable would be ideal as @jeremytenjo has said. Would really help incremental adoption for those who want to try this without changing root business logic. |
Beta Was this translation helpful? Give feedback.
-
|
I too agree that ...so the With the new proposed |
Beta Was this translation helpful? Give feedback.
-
|
routes as default and making it configurable in next.config.js seems like the best option :) |
Beta Was this translation helpful? Give feedback.
-
|
I also strongly prefer using “routes” for this instead of “app”. Because I think it makes more semantic sense, but also because we have thousands of Blitz apps using “app” to organize all application code. |
Beta Was this translation helpful? Give feedback.
-
|
The app folder should definitely be configurable. I don't see any reason not to. |
Beta Was this translation helpful? Give feedback.
-
|
Great work on this RFC. I do want to start a topic of discussion based on my experience with... another framework :). I like the concept of parallel fetching. However, there are some cases where it simply makes more sense for a parent route to provide data to child routes when fetching server props. For instance, you might have routes that use a common Is there a way to somehow serially load some data and load other bits of data in parallel? In particular, there was a situation where I wanted to redirect all child routes based on a result from a |
Beta Was this translation helpful? Give feedback.
-
|
One use-case I have in mind is about dealing with JWT authentication and Refresh tokens. With the current state of the RFC regarding parallel data-fetching, I feel like all segments |
Beta Was this translation helpful? Give feedback.
-
|
Auth for parallel loading can definitely be a headache. But, I don't believe Let's use the request from the illustration as an example: /dashboard/settings When the request comes in, Let's say SettingsPage receives an expired JWT and throws an error to cancel it's rendering. And, let's say DashboardLayout does three things:
When the retry request is received, the JWT is updated and your This same design works for "protected routes". Let's look at the same request to /dashboard/settings, but assume there is no JWT instead of an expired JWT. SettingsPage receives no JWT and throws an error. DashboardLayout receives no JWT and issues a 301 redirect to /sign-in, where the user can sign in. This is moreorless how Clerk solved this problem for Remix, which faces the same challenges. The solution depends on two things:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing details regarding the authentication flow. In our original implementation, we were actually doing the refresh token logic in an Edge Middleware. This middleware was actually doing a redirection on Regarding |
Beta Was this translation helpful? Give feedback.
-
|
Love this discussion! Yeah my use-case using another framework was a bit different. Basically, we had to show different routes depending on what access the user has. If they didn't have admin access, but they attempted to access an admin route, we'd just redirect them to a 404 page. On every nested route that used a loader we would add a call to the Some other solutions I looked into: potentially using a request cache so that for the same request the loaders could race to create the promise and then the promise would be awaited. The problem was that there was no way of distinguishing the request from another, and I didn't want there to be request collisions between users (the system was multi-tenant so this would have been REALLY bad). I also looked into adding some kind of request ID but I would have needed to make some bigger changes. And another solution I looked into was a server-side cache of some sort, potentially using Redis, but again super heavy-handed and then we had the problem of having to invalidate that cache somehow. Anyhow I gave up on that framework and just went back to plain old CSR. |
Beta Was this translation helpful? Give feedback.
-
|
I can think of a workaround for this problem given the current architecture of Nextjs layouts, but I'll admit it feels a bit hacky... A module that holds your shared data, and provides async getters for it. This module is imported by all files in the layout chain that need the common data, and they call the getter that would otherwise call the data source (be it DB, an HTTP request or whatever your source of truth is) multiple times. In SSR, the getter call could take the request object, and check it against a WeakMap. If it doesn't exist, set the request as the key in the WeakMap, with the promise for the data as the value. Later, when the same getter is called by another route in the chain, return the promise for that request. Because it is a WeakMap, after the request is handled, the garbage collector should remove the promise from the weak map automatically. From the view point of the caller, they all just await the promise they got from the WeakMap. Whoever calls it first will block on it (while other ones will continue to work until they too need the same data, and then they all wait), and whoever calls it after that will essentially get the data immediately. You could have multiple different operations stored in the same WeakMap value, stored as an object of named promises, and return the corresponding one based on the getter call, always initializing the "placeholder" object to an empty one when the request object is not an existing key in the WeakMap. You're sacrificing a tiny bit more memory than you would otherwise (allocating the module and the WeakMap itself), in order to get great speed saving (no second data source lookup + parallel execution where possible) and DX (no passing down of data in a waterfall). On the client side, the same approach can be used, except that you would not pass a request - just maintain the entire thing as a singleton. For "bonus points", in both client and server side, you could spawn a worker thread for the actual storage and retrieval. A thin client on the main thread would merely resolve the promise on a message from the worker. That's once again some more memory (for the whole second thread...) for the luxury of letting everything else happen on the main thread at the same time. That last part is essentially what comlink is for. |
Beta Was this translation helpful? Give feedback.
-
|
I'm very excited for what Layouts will enable!!! I have many questions. It's unclear to me how I saw that _app was mentioned; however, I saw no reference of _error, _404, and _500. Will there be equivalent files per segment? Since we can potentially expect error responses from multiple data fetching methods, will either the methods OR the custom components be getting an updated API to allow developers insight into which data fetch caused the issue?
Is it possible for a segment to have a Lastly, I was disappointed to see this:
What I can't ignore is that it feels like Server Components are not around the corner. Layouts has been a big need in Next.js for a long time, and I feel like connecting this to multiple React features that are still in RFC and/or unreleased may lead to this taking way longer than necessary. At the very least |
Beta Was this translation helpful? Give feedback.
-
Adopting Server Components doesn’t mean that the route will be SSR’d on every request. If it doesn’t have SSR data fetching (getServerSideProps) in all its layouts, the route will be statically optimized at build time just like what we have today. |
Beta Was this translation helpful? Give feedback.
-
That's really good to hear. I didn't realize that. |
Beta Was this translation helpful? Give feedback.
-
|
@shuding Does that imply that you can statically render parts parts of the tree and dynamically render others? That would actually be really cool. |
Beta Was this translation helpful? Give feedback.
-
|
@mAAdhaTTah In some cases, yes! The exception will be “static sub-layout under dynamic layout”, where the static sub-layout can’t be real static anymore, because you can pass dynamic data (via context) to it. |
Beta Was this translation helpful? Give feedback.
-
|
Circling back @timneutkens you mentioned that my earlier bit would be covered by part 2, but I don't see it explicitly mentioned here. I think I get the picture on how it's a paradigm shift (no need for _500, _404, or _error because they're no longer going to be page-wide errors. Instead, they'll be component-level tree errors. That being said, I think you would probably still want layout-level or page-level handling for 404 and 500.
|
Beta Was this translation helpful? Give feedback.
-
|
I could be missing something, but what if we need to pass Maybe a layout.js component should accept a |
Beta Was this translation helpful? Give feedback.
-
|
You have a really good point. IMHO a helper method (probably in the form of a hook) should tell how deep you are in a subtree, shared data/context from parent/child segments and a way to conditionally refresh a parent segment data. Remix offers hooks for those scenarios (like useMatches) and allows to use segment data in any layout with an array of all the nested parts of the route. Something similar will definitely need to exist. There's a note in the RFC regarding refreshing data on a parent route that could also be relevant: "It will be possible to force a re-fetch of data higher up the tree. We are still discussing the details of how this will look and will update the RFC." |
Beta Was this translation helpful? Give feedback.
-
|
We're currently using React Router and looking into migrating to Next for a while. Nested Routes will definitely make this easier, but we heavily pass data from parent route segments to child route segments as well. Is it allowed to have a function as I'd like to avoid Context, because it increases the indirection and is more verbose. It would of course also be nice if TypeScript can properly check this (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
You will have to use something like Context for this case (will add examples for this). A layout and its children aren’t simply wrapped together like normal components, but can be a Server/Client Components pair: So actually all the levels of nested layouts can be rendered in different environments, and we can’t pass any arbitrary props between them (e.g. a callback function) but only serializable ones, that’s why we need a new way to do this. |
Beta Was this translation helpful? Give feedback.
-
|
Can React Context cross the Server/Client boundary like that? My understanding is you're going to end up with Server & Client Context as separate things, which would make using Context for this difficult/impossible. |
Beta Was this translation helpful? Give feedback.
-
This sounds like a good option. I think this kind of functionality is essential. I have a Parent component where I want my logic and state to live. Nested within that Parent I want to navigate through multiple Child pages which all use the state passed down from the Parent. Without using Context this isn't possible, but for some simple things it seems like overkill. There are ways to get the React Router working within Next.js projects, so it must be something they can build into Next.js? |
Beta Was this translation helpful? Give feedback.
-
|
This is absolutely so exciting! So happy to see support for this finally, and I cant' wait to see it roll out... speaking of which, any ETAs on when we could see this hit Next? This is truly a game-changer for Next and will make development so much better on larger, complex sites. |
Beta Was this translation helpful? Give feedback.
-
|
Even a very rough estimate would be helpful i.e. 6-8 weeks? 3-6 months? Sometime in 2023? |
Beta Was this translation helpful? Give feedback.
-
|
We still are not at the point where we can provide a public estimate for this, but we have several members of the core team working on this as their primary project, and are already months into implementation work if that helps at all. As soon as we are confident enough to drop a public estimate we will do so, and we will also offer testing on a canary build before stable release as we do with all nextjs features 😁 |
Beta Was this translation helpful? Give feedback.
-
|
How will passing data from the page level up to the root layout work? |
Beta Was this translation helpful? Give feedback.
-
|
For your example, you could use the |
Beta Was this translation helpful? Give feedback.
-
|
Okay, what if I just need page data to pass to other components that are in the root Layout? |
Beta Was this translation helpful? Give feedback.
-
|
You could use the Context API and share data through multiple components in the layout tree using hooks. |
Beta Was this translation helpful? Give feedback.
-
|
Context should be used sparingly, so it seems like more of a band-aid solution. It's strange that nothing has been built into this layout project that allows for this type of props passing. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think that's inherently a bad idea. Context is a powerful solution that if used correctly, or with the help of a third party package like It's robust and reliable and by the looks of it it may be the best solution for your needs, unless you have some strict requirements that prevent you from using it. |
Beta Was this translation helpful? Give feedback.
-
|
Great write up, and layout RFC makes nextjs finally on par with CSR in the shared layout use case. Just 1 quick question, does it ditch the client-side caching? Which means, there is no concept of client-side caching anymore, and onServerSideProps will always "send" a request since it's on the server and has no knowledge of client-side caching? What about I want to cache certain requests for a certain times or certain conditions? Also, on a CSR app, for subsequent requests for a request X, libs like react-query would return the old cache first, then doing a refetch underneath, so the page will render instantly but only re-renders when there is new data from server. This leads to a smooth UX, is it still possible with this RFC? How does layout RFC play with this use case plz? 😃 |
Beta Was this translation helpful? Give feedback.
-
|
any news on when they gonna release it? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hidden both comments as they're off-topic. The first comment is completely incorrect and seems to be an assumption not backed by any data. @sopuku keep an eye on https://nextjs.org/conf 🙌 |
Beta Was this translation helpful? Give feedback.
-
|
From Next Conf. I think RC version will ship in 18 Oct and released in 24 or 26 Oct |
Beta Was this translation helpful? Give feedback.
-
|
Your guess is as good as anyone else's. We won't know at least until Next.js Conf which will be on the 25th of October, so... 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice to have a way to return only the components without any wrappers (headers, scripts ...), something similar could be done before with |
Beta Was this translation helpful? Give feedback.
-
|
super excited for this 😄 |
Beta Was this translation helpful? Give feedback.
-
|
trying to implement the rfc app directory. i encounter this error "Error: > Couldn't find a |
Beta Was this translation helpful? Give feedback.
-
|
Read this thread #37136 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
thanks dude, cant wait for the rfc |
Beta Was this translation helpful? Give feedback.
-
|
Hello. |
Beta Was this translation helpful? Give feedback.
-
|
It frequently changed, CSR, if not, ISG |
Beta Was this translation helpful? Give feedback.
-
|
Yes, how do they handle it? |
Beta Was this translation helpful? Give feedback.
-
|
Looks good but I'm curious about storing API logic along side each conceptual group of code. Right now it's a bit weird to store client side things and API utility code in /app/thing — then have to also maintain a /pages/api/thing directory. Will it be possible to store API routes along side their client side friends in the /app directory? |
Beta Was this translation helpful? Give feedback.
-
|
This seems like it will work very well for "apps" where the layout is often defined by the path and known in advance. I'm not clear on how this will work for sites where the layout is dynamic and based on the page or "slug". On our site, we need to fetch layout data from our CMS on a per-page basis. Most of the time this data is the same from page to page, but it could potentially change even within the same dynamic route. Layouts can also be variable within the same page if an A/B test is active. It seems like we would need a way to access page props within the Layout component. |
Beta Was this translation helpful? Give feedback.
-
|
Wanted to follow up here with another update: we will be sharing more about this next week at Next.js Conf. |
Beta Was this translation helpful? Give feedback.
-
|
Any examples with RFC layouts? Also can we safely use this for auth pages too? Or it is meant only for non-auth pages? |
Beta Was this translation helpful? Give feedback.
-
|
add to |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, I will give a try |
Beta Was this translation helpful? Give feedback.
-
|
With the current state of the RFC, we’ll have to remember which file names are special to Next.js. Here’s a quick quiz: Which of these files are special to Next.js and which files are custom components that are colocated within the route folder?
👉 Show answer
Did you get the correct answer? Also, with the current naming scheme, any new special files that gets added in the future can become a breaking change, if it clashes with pre-existing colocated files. SvelteKit resolves this issue by designating a reserved prefix for files that are treated specially by the framework. This way that it’s easier for humans to easily tell the difference between colocated files and special files, as text editors will display files with a prefix separately from files without prefix. Here’s what the editor file tree will look like if Next.js special files are prefix with |
Beta Was this translation helpful? Give feedback.
-
|
an icon theme is nice, but I really wish that the names had some prefix convention to mark that they are significant. Not everyone uses VSCode. I feel like any additional co-located components will decrease the signal to noise ratio without that. |
Beta Was this translation helpful? Give feedback.
-
|
I totally agree with you. Prefixing with underscore etc. would make a huge difference. There has been lots of discussion about naming conventions but I haven't seen any official feedbacks that there would be some changes. |
Beta Was this translation helpful? Give feedback.
-
|
Sadly, I haven't either. Granted: I haven't scrubbed through all the hours of the nextjs conf footage, but from what I can tell they've not brought anything up. just to finish fleshing out a thought: I wonder also if a hybrid of this and the previous methodology might work better. (which might be worth putting in it's own post? - unsure - new here). would become full benefits of the inheritence model that they're going for, better DX for contextual awareness (ie: filenames you're working in), and the |
Beta Was this translation helpful? Give feedback.
-
|
or... 1 file, with named exports. export const Layout = () => <></>
export const Loading = () => <></>
export const Page = () => <></>
export const Error = () => <></> |
Beta Was this translation helpful? Give feedback.
-
|
I follow the logic, but I can't say I agree. I tend to use a lot of common components named things like Layout. |
Beta Was this translation helpful? Give feedback.
-
|
In Next 13, will all components be Server Components by default or only the ones that are in the "app" directory? |
Beta Was this translation helpful? Give feedback.
-
|
From the look of the new docs I think they will be, and Client Components will have |
Beta Was this translation helpful? Give feedback.
-
|
Congrats on the release of next 13! 🙌 No love for named exports? |
Beta Was this translation helpful? Give feedback.
-
|
Update: We’re excited to announce Next.js 13, which includes the new Inside the You can leave feedback here: #41745 |
Beta Was this translation helpful? Give feedback.
-
|
The App Router is now stable with 13.4! |
Beta Was this translation helpful? Give feedback.
and others
-
Update: #37136 (comment)
This RFC outlines the biggest update to Next.js since it was introduced in 2016:
👉 Read the RFC – we'd love to hear your feedback and comments.
Beta Was this translation helpful? Give feedback.
All reactions