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

retrieving the value of a field within an array

What could be causing my controller method in TypeScript to throw an error message unexpectedly?

Acquiring radio button input in PHP

Utilize JavaScript to submit the FORM and initiate the 'submit' Event

The beauty of crafting intricate forms with Angular's reactive nested

The installation of AngularJS libraries via npm was unsuccessful

Switch button displaying stored data in sessionStorage

The Dropdownlist jQuery is having trouble retrieving the database value

Verifying that a parameter is sent to a function triggering an event in VueJS

Managing time-intensive web service operations using JavaScript callbacks

How to switch the code from using $.ajax() to employing $.getJSON in your script

Is it feasible to embed Instagram in an iframe without using the API?

Troubleshooting: How to Fix Missing Sum Display in HTML Input Fields

Add the $scope ng-click event to a previously hidden element once it becomes visible

What is the best way to conceal a header on a single page within a Next.js application?

The attempt to retrieve the image from the specified URL at https://res.cloudinary.com/<------.jpg> was unsuccessful with a 404 error

There is a button on my website that uses a small piece of Javascript to post a tweet, but unfortunately, it is not functional on mobile devices

The JavaScript-generated form element will not be included in the data submitted through the POST method

Discovering the oldest date in an array with JavaScript

The information is retrieved from the backend system, yet it fails to appear on the user interface