这是推荐的 Next.JS 文件夹结构吗?

IT技术 javascript reactjs project-management next.js
2021-05-08 11:20:16

我们采用了以下项目结构

|- 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__

澄清一下,没有任何问题,而且效果非常好。我们有在components目录内的多个页面中复用的组件,我们按如下方式导入

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

此外,仅使用一次的组件并排位于其pages文件夹中。

我们现在面临的唯一问题是热module重新加载被破坏,即每当我们.jsxpagescomponents目录中编辑文件时,我们必须手动重新加载页面以查看生效的更改(它不会影响 CSS 文件)。这是我们已经习惯的事情,因此不会严重影响我们。

我的问题是,是否有任何我们不知道的即将发生的灾难?

4个回答

在自己为 NextJS 寻找合适的文件夹结构时偶然发现了这篇文章。我一直在使用类似的结构,但最近发现这不是您使用 NextJS 的方式。

细节我不太了解,但是NextJS在页面层面有优化。当您构建 NextJS 项目时,您将看到作为构建的一部分记录的页面。NextJS 将文件pages下的每个组件文件都视为一个页面,因此通过在pages文件夹中放置非页面组件,您将大大增加构建时间,因为现在 NextJS 将这些组件中的每一个构建为一个页面。

我喜欢这篇文章中提出的结构

https://medium.com/@pablo.delvalle.cr/an-opinionated-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

对于所有对此仍然感兴趣的人,我个人推荐这种方法,因为它有助于划分资源并允许快速查找内容和进行单元测试。

它的灵感来自 HackerNoon 的一篇关于如何构建 React 应用程序的文章

这是我推荐的,使用module化设计模式:

/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

我写了一篇关于它的文章:https : //dev.to/vadorequest/a-2021-guide-about-structuring-your-next-js-project-in-a-flexible-and-efficient-way-472

唯一真正需要注意的是,页面下不能有任何不是实际页面或 API 端点的内容(例如:测试、组件等),因为无法忽略它们,Next 将进行捆绑和部署它们作为实际页面。