There will be too many `page.js`, `layout.js` in the editor at the same time, which can be confusing.
Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
81–90 of 123 posts
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#82Every time I hear any news about routing in a React framework I always get disappointed that the news isn't that they're introducing type-safe (TypeScript) routes to enable type-safe linking.
I'm curious about what you mean. There's no way to embed type information into a URL - every GET parameter is a string. Are you suggesting that visiting a link like /123 would go to the ' string: "123" ' route, while clicking a would route you to ' number: "123" '? That would make deep linking in an app really hard to manage. I'm struggling to understand why you'd want to overload routes like that.
I'm pretty sure what they are looking for is that something like a Link that takes a route name and a params object that are both typed.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#83I am not a fan of the “directory structure creating an implicit router” convention of next.js. I wish I would define a handler in code instead.
Coming from a React Router background, the Nextjs file structure is a bless to work with
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#84Earlier quoted context omitted.
> Are next.js and other similar React frameworks worth looking at if you don't use node.js on the backend? It depends on why you’re doing so. We’ve recently moved from a C# .net backend to a TypeScript node backend and in such a case it (well obviously) makes perfect sense to utilise next.js. In other cases where you split your front end and backend quite clearly, like using .net APIs and a JS front end it can make s…
I've heard people suggest to always use Next.js, because the alternative (Creat-React-App) is being developed too slowly.
CRA isn’t really an alternative because it doesn’t have a server-side component. It’s also a lot less opinionated around things like routing. I’d say Remix is probably the main competitor to Next, that’s built around React Router and already has support for nested routes/layouts, and has opinionated support for the server-side too.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#85Every time I hear any news about routing in a React framework I always get disappointed that the news isn't that they're introducing type-safe (TypeScript) routes to enable type-safe linking.
I'm curious about what you mean. There's no way to embed type information into a URL - every GET parameter is a string. Are you suggesting that visiting a link like /123 would go to the ' string: "123" ' route, while clicking a would route you to ' number: "123" '? That would make deep linking in an app really hard to manage. I'm struggling to understand why you'd want to overload routes like that.
Generating a set of links from the routing as a union of strings as type Route. And a component that only accepts an href of that type.
Like so: https://www.typescriptlang.org/play?jsx=4#code/C4TwDgpgBASg9...
TS' string literal types are powerful.
https://www.typescriptlang.org/docs/handbook/2/everyday-type...
edit: I did implement this a while back but found it gave me only so much additional value. Though I can imagine that large applications with dozens of developers might indeed benefit from type-safe routes to avoid dead links.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#86Earlier quoted context omitted.
Oh interesting. Why not? Directory and file based routing is my favorite feature of Next.js, Remix, and other frameworks that do it.
It makes route localization a second-class citizen in the framework at best, or a totally unsupported hack-your-own-solution thing at worst.
if it helps, you could use middleware in next.js to handle routing to separate folders easier.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#87Earlier quoted context omitted.
I'm curious about what you mean. There's no way to embed type information into a URL - every GET parameter is a string. Are you suggesting that visiting a link like /123 would go to the ' string: "123" ' route, while clicking a would route you to ' number: "123" '? That would make deep linking in an app really hard to manage. I'm struggling to understand why you'd want to overload routes like that.
Generating a set of links from the routing as a union of strings as type Route. And a component that only accepts an href of that type. Like so: https://www.typescriptlang.org/play?jsx=4#code/C4TwDgpgBASg9... TS' string literal types are powerful. https://www.typescriptlang.org/docs/handbook/2/everyday-type... edit: I did implement this a while back but found it gave me only so much additional value. Though I can ima…
That's an interesting idea. Cheers.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#88I am not a fan of the “directory structure creating an implicit router” convention of next.js. I wish I would define a handler in code instead.
I've worked with both. There are days when I prefer a programmatic approach, and days I love the file-based router. With the introduction of routing middleware [0], Next.js finally offers anything I'd want to build.
An option would be to add a catch-all route [1] at the root and implement your own code-based routing. You can still define the desired paths using getStaticPaths [2] but my guess is that some functionality like route-based code splitting will stop working.
0 - https://nextjs.org/docs/advanced-features/middleware
1 - https://nextjs.org/docs/routing/dynamic-routes#catch-all-rou...
2 - https://nextjs.org/docs/basic-features/data-fetching/get-sta...
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#89There will be too many `page.js`, `layout.js` in the editor at the same time, which can be confusing.
[deleted]
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#90I am not a fan of the “directory structure creating an implicit router” convention of next.js. I wish I would define a handler in code instead.
Oh interesting. Why not? Directory and file based routing is my favorite feature of Next.js, Remix, and other frameworks that do it.
I don't like this approach either as maintenance gets complex over time. Changing routes in my React-router project is one file, one commit that's easy to verify, try changing a dozen routes with Next and you end up with a dozen of files moved around, with folder structure possibly impacted as well, I see this as an anti-pattern.