Live data from Hacker News

Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

nextjs.org

111–120 of 123 posts

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#111
post #76

Every 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.

Shameful ad for our own router: https://swan-io.github.io/chicane, with type-safe route consumption and creation (and other goodies).

No weirdness or magic API, the useRoute hook just return a discriminating union with typed params. It's fully-featured and used in prod.

The API is quite simple:

const Router = createRouter({ UserDetail: "/users/:userId" });

Router.UserDetail({ userId: "xxx" }); // safe

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#112
post #14

Earlier quoted context omitted.

According to Ryan Florence (Remix's creator) they are "ripping features straight from Remix". https://twitter.com/ryanflorence/status/1528859776930545665

It’s an odd claim, because people have been asking for this (nested routes) more-or-less since Next was first released. In fact, Remix is basically a compiler for the patterns we could achieve back in the days of React Router 2 and 3 (2015-2017). The fact that the APIs looks similar seems largely inevitable based on the fact that everyone seems to be converging around defining routes using folder and file name conven…

> Remix is basically a compiler for the patterns we could achieve back in the days of React Router 2 and 3

Well, Remix and react-router are by the same people.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#113

Earlier quoted context omitted.

Ryan and his insufferable Remix evangelists are the reason I never went beyond a quick hello world. And I like the concept. A while ago he had a Twitter series “spot a React app” where he just shits on other peoples work. Such an odd way to promote his work.

> insufferable Remix evangelists That is so true. It's been driving me insane since Remix was announced/opened but I couldn't quite put my finger on why. It's because overnight there was an army of people preaching the new religion of Remix all over the place, and not a single one I asked could (at the time at least) tell me why it was better/different than Next.js (a project which IMHO rose on its merit and had to f…

Yeah this is really common in people trying out niche things.

Not only in software. Remember the "Don't worry, they'll tell you" jokes about vegans and crossfit?

I think it must be some sort of evolutionary strategy to justify the risk/anxiety of going against the group.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#114
post #6

We're irrationally excited about this internally and we're super happy with how the Vercel team has continued to push Next.js forward. Thank you! We're using a version of the persistent layout pattern Adam Wathan [blogged about]( https://adamwathan.me/2019/10/17/persistent-layout-patterns-... ) but having first-class support for this paradigm will be awesome.

Thank you! We've added documentation[1] on the current layouts solutions, which is similar to Adam's post. It's a good workaround, but I'm very excited for improving the developer experience here. [1]: https://nextjs.org/docs/basic-features/layouts

There's a fundamental flaw with the solution proposed in the documentation (getLayout as a function), which could be fixed by using a pure JSX approach: https://github.com/vercel/next.js/issues/36029

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#115
post #60

Earlier quoted context omitted.

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.

Middleware won't work if you use "next export" to get a truly static site though, which is by far my preferred mode of operation whenever possible.

This is what I meant when I said "second-class citizen at best".

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#116
post #14

Earlier quoted context omitted.

According to Ryan Florence (Remix's creator) they are "ripping features straight from Remix". https://twitter.com/ryanflorence/status/1528859776930545665

Which is a bit silly, to be honest. I understand wanting to see some credit given, and it wouldn't have cost Vercel anything to do so, but this is hardly "new Remix technology" that they're copying (also the condescending "React czar" stuff is just super inappropriate, but par for the course with the way the Remix team has been talking about Remix on Twitter since the days when they were boasting about not taking VC…

Remix creators inspired by Ember.js as they mentioned years ago in one of the blogpost about the new concept and philosophy.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#117
I'm totally not sold about this.

Next.js routing was wrong from the start, and now it introduces a tons of new concepts that will inevitably require the rewriting of entire apps in a far future, since it will be "the new way to do routing in Next.js".

What I really don't like is the coupling between the filesystem hierarchy and the actual routes, that is difficult to reason about when you have non english routes names with multiple route parameters.

I mean, the routing problem for server side applications was solved a lot of time ago: a simple regex for the route definition, and the related handler that will responde to that route.

I never understood why Next.js guys went with this inconvenient approach of the file system routing.

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#118
post #60

Earlier 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.

It seems like a path prefix like "/en/books" or "/es/books" could be supported with a base url config.

Localized path segments like "/books" or "/libros" could be supported with a path segment mapping configuration.

It should work fine in theory. I guess those configs don't exist yet. Or is there something else that route localization requires?

Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components

#119

Earlier 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.

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.

That's true, the pull request diff viewer does not make viewing file renaming very clear and there could be conflicts.

On the other hand, what I see in practice is adding or removing context providers and layout components in the react router file, it becomes huge, and all the diffs change all of the lines with new indentation.

Post reply on HN