¿Se recomienda esta estructura de carpetas Next.JS?

Hemos recurrido a esta siguiente estructura de proyecto

|- pages
    |- <page_name>
        |- index.js             # To do a default export of the main component
        |- MainComponent.jsx    # Contains other subcomponents
        |- main-component.css   # CSS for the main component
        |- OtherComponents.jsx  # more than 1 file for child components that are used only in that page
        |- __tests__            # Jest unit and snapshot tests
|- components
    |- index.js                 # Exports all the default components of each component as named exports
    |- CommonCmpnt1
        |- CommonCmpnt1.jsx
        |- common-cmpnt-1.css
        |- index.js             # To default export the component
        |- __tests__
    |- CommonCmpnt2
        |- CommonCmpnt2.jsx
        |- common-cmpnt-2.css
        |- index.js             # To default export the component
        |- __tests__

Para aclarar, nada se ha roto y funciona increíblemente bien. Tenemos componentes que se reutilizan en varias páginas dentro del components directorio, donde importamos de la siguiente manera

// Assuming we are inside MainComponent.jsx
// ...
import { CommonCmpnt1 } from '../../components';    // We even take it a step further and use absolute imports

Además, los componentes que se usan solo una vez residen uno al lado del otro en su pages carpeta.

El único problema al que nos enfrentamos ahora es la recarga del Hot Module se interrumpe, es decir, cada vez que editamos el .jsx archivo dentro del pages o el components directorio, tenemos que volver a cargar manualmente la página para ver los cambios realizados (no afecta a los archivos CSS). Es algo a lo que nos hemos acostumbrado y por lo tanto no nos afecta seriamente.

Mi pregunta es, ¿hay alguna catástrofe inminente que no sepamos?

Tropecé con esta publicación mientras buscaba una estructura de carpetas adecuada para NextJS. He estado usando una estructura similar, pero recientemente descubrí que esto es no cómo se supone que debes usar NextJS.

No sé mucho sobre los detalles, pero NextJS tiene optimizaciones a nivel de página. Cuando crea un proyecto NextJS, verá las páginas registradas como parte de la construcción. SiguienteJS golosinas cada archivo componente bajo la pages carpeta como una página, por lo que al colocar componentes que no son de página en la pages carpeta, eres drásticamente aumentando el tiempo de construcción porque ahora NextJS va y construye cada uno de esos componentes como una página.

Me gusta la estructura propuesta en este artículo.

https://medium.com/@pablo.delvalle.cr/una-opinion-basic-next-js-files-and-directories-structure-88fefa2aa759

/root
  \_ /.next/
  \_ /components/
      \_ Button/
          \_ button.spec.jsx
          \_ button.styles.jsx
          \_ index.jsx
  \_ /constants/
      \_ theme.js
      \_ page.js
  \_ /contexts/
      \_ Locale/
         \_ index.js
      \_ Page/
         \_ index.js
  \_ /pages/
      \_ _app.jsx
      \_ _document.jsx
      \_ about.jsx
      \_ index.jsx
  \_ /providers/
      \_ Locale/
         \_ index.js
      \_ Page/
         \_ index.js
  \_ /public/
      \_ favicon.ico
      \_ header.png
  \_ /redux/
      \_ actions/
         \_ users/
            \_ index.js
         \_ products/
            \_ index.js
      \_ reducers/
         \_ users/
            \_ index.js
         \_ products/
            \_ index.js
      \_ store/
         \_ index.js
      \_ types/
         \_ index.js
  \_ /shared/
      \_ jsons/
          \_ users.json
      \_ libs/
          \_ locale.js
      \_ styles/
          \_ global.css
  \_ /widgets/
      \_ PageHeader/
          \_ index.jsx
  \
  \_ .eslintignore
  \_ .eslintrc
  \_ .env
  \_ babel.config.js
  \_ Dockerfile
  \_ jest.config.js
  \_ next.config.js
  \_ package.json
  \_ README.md

Si alguien todavía está interesado, guardo el archivo según su tipo en mi proyecto, por ejemplo:

|-Nextjs-root
  |-Components
    |-Header.js
    |-Footer.js
    |-MoreExamples.js
  |-styles
   |-globals.css
   |-header.module.css
   |-footer.module.css
  |-Services
    |-api              #Axios config to connect to my api
  |-Context
   |-AuthContext.js    #Global context to my app for auth purposes
  |-pages
   |-index.js

Para todos los que todavía están interesados ​​en esto, personalmente recomiendo este enfoque debido a que ayuda a compartimentar los recursos y permite encontrar cosas rápidamente y realizar pruebas unitarias.

Se inspiró en un artículo de HackerNoon sobre Cómo estructurar su aplicación React

Esto es lo que recomiendo, usando un patrón de diseño modular:

/public
    favicon.ico
/src
    /common
        /components
            /elements
                /[Name]
                    [Name].tsx
                    [Name].test.ts
        /hooks
        /types
        /utils
    /modules
        /auth
            /api
                AuthAPI.js
                AuthAPI.test.js
            /components
                AuthForm.tsx
                AuthForm.test.ts
            auth.js
    /pages
        /api
          /authAPI
              authAPI.js
          /[Name]API
              [Name]API.js
        _app.tsx
        _document.tsx
        index.tsx

Escribí un artículo al respecto: https://dev.to/vadorequest/a-2021-guide-about-structuring-your-next-js-project-in-a-flexible-and-ficient-way-472

Lo único con lo que realmente debe tener cuidado es no tener nada debajo de las páginas que no sean páginas reales o puntos finales de API (por ejemplo, pruebas, componentes, etc.), porque no hay forma de ignorarlos y Next los empaquetará y desplegará. como páginas reales.

La forma que ahora me conviene más es usar el pages carpeta solo para fines de enrutamiento, los componentes en cada archivo son solo un contenedor para el “real” componentes de página en src carpeta. Con este enfoque, puedo estructurar mi página de inicio con mayor facilidad y se siente más intuitiva, para contener el diseño y sus componentes secundarios en la misma carpeta.

Asegúrese de separar los archivos de solo backend de los archivos de frontend + backend

Independientemente de cómo los llame, recomendaría tener dos directorios con una semántica muy clara:

• el directorio de solo backend: puede realizar operaciones solo de backend, por ejemplo, accesos directos a la base de datos o al sistema de archivos (require('fs'))
• el directorio frontend + backend: solo cosas seguras frontend. Dado que Next.js es una configuración de SSR, cualquier cosa que sea segura para el frontend también debe ser segura para el backend, por lo que también puede usarla desde el backend, por ejemplo, configuraciones compartidas o ayudantes.

Esto es importante porque de lo contrario comenzarás a encontrar errores como:

Módulo no encontrado: no se puede resolver ‘fs’

al factorizar las cosas con HoC, y como se menciona en Módulo no encontrado: No se puede resolver ‘fs’ en la aplicación Next.js. No sé cómo resolver esto, excepto haciendo esta división clara y definitiva.

Tal vez esta sea la semántica intencionada de la lib/ contra components/ convención de uso común, pero no pude encontrar una cita clara.

Estoy más tentado a simplemente llamarlos back/ y front/

ESLint pages/, components/y lib/ por defecto

Este es el único efecto claro en el código ascendente de components/ y lib/ que pude encontrar como se menciona en: https://nextjs.org/docs/basic-features/eslint#linting-custom-directories-and-files (pages/ por supuesto es mágico y contiene los puntos de entrada de URL, y obviamente no deberías poner nada más ahí):

De forma predeterminada, Next.js ejecutará ESLint para todos los archivos en los directorios pages/, components/ y lib/.

No importa mucho en ese caso, ya que la lista de directorios se puede configurar fácilmente como se documenta allí.