A guide to organizing page components across multiple `/pages` directories in a Next.js application

Question

A guide to organizing page components across multiple `/pages` directories in a Next.js application

As I delve into my first project using Next.js, I find that my pages directory has expanded significantly. Now, I am keen on organizing my pages by grouping them into modules, resulting in a structure like 'src/modules/*/pages/*'.

In my quest for solutions, I stumbled upon exportPathMap, a function that can be integrated into my next.config.js file to create custom paths for my pages. However, the thought of having to add a new path for each page seems quite tedious. What I desire is to provide Next with a singular expression such as 'src/modules/*/pages/*', allowing it to automatically resolve the pages and routes (similar to mapping entities in an ormconfig.json file when working with TypeORM).

One approach could involve grouping my page components directly within the pages directory, like pages/a-module/*. Yet, this does not address the segregation of components, hooks, and other logic into distinct modules. Another option might entail utilizing Node's fs module to navigate through my project's file structure and map the page folders. Nevertheless, I prefer to avoid this method if possible.

javascript next.js

Answer 1

Answer №1

If you want to simplify your directory structure, consider using symbolic links (symlinks). Instead of creating a symlink for every nested path within each module, only create symlinks for the modules themselves. For example:

├── modules
│   ├── bar
│   │   └── pages
│   │       ├── first.js
│   │       └── second.js
│   └── foo
│       └── pages
│           ├── first.js
│           └── second.js
├── pages
│   ├── _app.js
│   ├── bar -> ../modules/bar/pages
│   ├── foo -> ../modules/foo/pages
│   ├── index.js

This setup would result in routes such as:

/bar/first
/bar/second
/foo/first
/foo/second

However, be cautious as this approach may introduce clutter into your modules folder similar to what you previously had in the pages directory. Remember that not all component content needs to reside directly in the pages files. You can keep it separate like so:

// pages/foo/first.js
import FirstContent from '../../modules/FirstContent'

export default function First() {
  return <FirstContent />
}

Answer 2

If you want to simplify your directory structure, consider using symbolic links (symlinks). Instead of creating a symlink for every nested path within each module, only create symlinks for the modules themselves. For example:

├── modules
│   ├── bar
│   │   └── pages
│   │       ├── first.js
│   │       └── second.js
│   └── foo
│       └── pages
│           ├── first.js
│           └── second.js
├── pages
│   ├── _app.js
│   ├── bar -> ../modules/bar/pages
│   ├── foo -> ../modules/foo/pages
│   ├── index.js

This setup would result in routes such as:

/bar/first
/bar/second
/foo/first
/foo/second

However, be cautious as this approach may introduce clutter into your modules folder similar to what you previously had in the pages directory. Remember that not all component content needs to reside directly in the pages files. You can keep it separate like so:

// pages/foo/first.js
import FirstContent from '../../modules/FirstContent'

export default function First() {
  return <FirstContent />
}

Answer 3

Answer №2

The Next.js team has intentionally prohibited this action for specific reasons addressed in this article and in the related discussions. Before attempting to manipulate the file structure in any way, it is recommended to review the conversations to fully understand the implications.

Answer 4

The Next.js team has intentionally prohibited this action for specific reasons addressed in this article and in the related discussions. Before attempting to manipulate the file structure in any way, it is recommended to review the conversations to fully understand the implications.

Answer 5

Answer №3

In agreement with @Roman Mkrtchian, it is advisable not to proceed in this manner. I recommend organizing your files into modules by structuring them similar to the following:

src
├── modules
│    ├── foo
│    |   └── pages
|    |       ├── one
|    |       |   ├── index.jsx
|    |       |   └── styles.js <- Use for `styled-components` or a css file
|    |       └── two
|    |           ├── index.jsx
|    |           └── styles.js
|    └── bar
|        └── pages
|            └── three
|                ├── index.jsx
|                └── styles.js 
├── shared
└── ...

An alternative approach can be considered. As pointed out by @erich2k8, not all component content needs to reside within files inside /pages. You could maintain a similar structure but place /pages directly under src:

src
├── modules
├── shared
└── pages
    ├── foo
    |   ├── one.jsx
    |   └── two.jsx
    └── bar
        └── three.jsx

For example, within src/pages/foo/one.jsx, you would import src/modules/foo/pages/one like so:

import OneContent from '../../modules/foo/pages/one';

const One = () => <OneContent />;

export default One;

While it may require creating new files for each page within /modules, this approach avoids potential difficulties with Next behavior.

Answer 6

In agreement with @Roman Mkrtchian, it is advisable not to proceed in this manner. I recommend organizing your files into modules by structuring them similar to the following:

src
├── modules
│    ├── foo
│    |   └── pages
|    |       ├── one
|    |       |   ├── index.jsx
|    |       |   └── styles.js <- Use for `styled-components` or a css file
|    |       └── two
|    |           ├── index.jsx
|    |           └── styles.js
|    └── bar
|        └── pages
|            └── three
|                ├── index.jsx
|                └── styles.js 
├── shared
└── ...

An alternative approach can be considered. As pointed out by @erich2k8, not all component content needs to reside within files inside /pages. You could maintain a similar structure but place /pages directly under src:

src
├── modules
├── shared
└── pages
    ├── foo
    |   ├── one.jsx
    |   └── two.jsx
    └── bar
        └── three.jsx

For example, within src/pages/foo/one.jsx, you would import src/modules/foo/pages/one like so:

import OneContent from '../../modules/foo/pages/one';

const One = () => <OneContent />;

export default One;

While it may require creating new files for each page within /modules, this approach avoids potential difficulties with Next behavior.

A guide to organizing page components across multiple `/pages` directories in a Next.js application

Answer №1

Answer №2

Answer №3

Similar questions

Troubleshooting Problems with Angular ng-include

Tips for appending the id of an active element to a URL

Confirm the value of $index and apply a specific style

Convert TypeScript-specific statements into standard JavaScript code

Sending the parameter with the URL and receiving the response in return

Are foreign characters the culprit behind the JSON parsing problem?

Encountering a persistent Unhandled rejection Error while utilizing NodeJs with Bluebird library

Processing two Array Objects can be achieved without resorting to the EVAL function

Want to learn about Google Apps Script Web App? Join us to dive into AJAX, leverage

Multer is experiencing difficulties in uploading files, yet it is not displaying any error messages

Update the text input field from a different webpage

Preventing an infinite re-render loop caused by event listeners in React

Having trouble establishing a connection between MongoDB and a Node.js Express server on my local machine

Updating the query parameters/URL in Node.js's request module

Using a curly brace in a React variable declaration

Leveraging colons in the process of object destructuring

Could you please ensure that the animation activates upon hovering over the "a" element?

What is the best way to import two components with the same name from different libraries?

JavaScript is throwing an error when clicking on functions and managing the z-index property

Add a style to every div except for the final one