Why using pages instead of a js file that has routes?

[stevemarksd]

The main reason I stayed away from next.js for so long (I've been used gatsby for years) was the pages folder.

Look this file name [slug].js... just look at that file name. I never seen anything like that and I'm not even sure how my filesystem will handle it...

I see these issues

• Weird naming
• Non conventional
• Some characters that are supported in the url are not supported on some filesystems
• Filesystems are different, and might lead to bugs
• I'm not confident about what exactly happens in this folder. Components are magically loaded...
• What if I want to import this file... import Post from './[post].js.. looks weird..
• Can it support typescript? If yes, I wonder if is included in the proper webpack build? or who is going to parse this file. Way too much magic that makes me think about things I shouldn't be thinking in the first place.
• Types between APP code and pages are lost and needs to be manually kept in sync (see images below about getStaticProps...)

I'd suggest something much more clearer

const routes = {
  post: {
    render: (props: PostPageProps) => <PostPage {...props}/>
    buildPath: (props: PostPageProps) => props.slug
  }
}

In this way everything is much more flexible, less magic.

All tutorials I see so far are using this convention of pages and I think is really putting me off. I'm sure there is a way to use programmatically, but is so little used that makes me worry using it because I might go into issues and nobody knows how to fix them.

[ninest]

I 100% agree with this. I've always thought Nextjs needs an option to specify router declaration similar to react-router. There are a few solutions though which may help.

1. Use custom page extensions

This lets you put files other than pages inside the pages/ directory. I guess this is more suitable if you want your app to have a better organization, so probably not a good solution for you

2. Write your page components in other files, then import and export them inside the pages/ directory

For example:

// modules/blog/blogPost.js
export default function BlogPost() {
  ...
}

export async getServerSideProps() {
  ...
}

// pages/blog/[slug].js
import BlogPost, { getServerSideProps } from "../modules/blog/blogPost";

export default BlogPost;
export { getServerSideProps };

This will let your customize where you write your page components.

I've written a short guide on this, which you can see if you're interested: dividing your app into modules. You can specifically see how to import and export API routes and pages

[stevemarksd]

Thanks, that's what I'm doing right now (2) and is pretty ugly... Next.js has some nice features that I would not like to reinvent.

[icyJoseph]

Nowadays, you can use _middleware and with code control how the user requests map to your page structure. I have for example a file called history.ts, which I used to map with next.config.js rewrites, to show requests that arrive to /year/month/day.

Since _middleware was released, I moved this to code, and put a test on it.

I am not sure I follow your last point, you do know you can InferGetServerSidePropsType in combination with typeof.

Finally, and this is an opinion piece so feel free to ignore it, but it looks like you are coming in with a "this is what works for me" attitude, and framing how you build an application from that angle, instead of learning how the frameworks does things. I am not bashing, nor saying that you shouldn't criticize and judge the framework decisions, so here's an attempt at addressing your list.

• Weird naming

This is a subjective appreciation, right? What's non-weird naming. It's only for dynamic routes that the [] notation is used. You can tweak this with next.config.js or _middleware

• Non conventional

To what you have come across up to this point, web development is as vast as the ocean

• Some characters that are supported in the url are not supported on some filesystems

This is actually an area where I would agree

• Filesystems are different, and might lead to bugs

There's tons of tests backing up this feature

• I'm not confident about what exactly happens in this folder. Components are magically loaded...

The default export from any file inside pages is rendered. _app wraps that default export.

• What if I want to import this file... import Post from './[post].js.. looks weird..

Why would you? other than to test it perhaps? types, props, constants, helpers, components, should not really be at pages level. Your dependencies should build up to the pages level, rather than downwards.

• Can it support typescript? If yes, I wonder if is included in the proper webpack build? or who is going to parse this file. Way too much magic that makes me think about things I shouldn't be thinking in the first place.

What's do you mean here? TypeScript with Next.js is as easy as creating tsconfig.json (leave it empty), installing typescript and @types/react, @types/react-dom and @types/node, changing one file to .ts, and running npm run dev. Done.

• Types between APP code and pages are lost and needs to be manually kept in sync (see images below about getStaticProps...)

Already touched on this using InferGetServerSidePropsType