2021 年关于如何以灵活高效的方式构建 Next.js 项目的指南

Next.js

通常的文件夹结构

灵活且“模块化”的文件夹结构

Next.js

Next.js 对于如何构建 Next.js 项目非常不以为然。

您唯一需要真正小心的是不要在pages它下面放置任何非实际页面的内容（例如：测试、组件等），因为没有办法忽略它们，并且 Next 会将它们捆绑并部署为实际页面。

您可以选择将代码放在根目录 ( /pages) 或目录下src( /src/pages)。我们更喜欢后者，因为它可以更清楚地显示哪些是实际与应用相关的代码，哪些不是。

通常的文件夹结构

大多数人会使用文件夹结构来组织他们的项目，例如：

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

    /pages
        /api
          /authAPI
              authAPI.js
          /[name]API
              [name]API.js
        _app.tsx
        _document.tsx
        index.tsx

这种设计模式非常常见，非常适合小型项目，因为它可以清晰地显示文件的存放位置。文件会根据“文件类型”进行分组。这与许多开发人员熟悉的 MVC 设计模式非常相似。

这种设计模式的主要问题是缺乏可扩展性。

虽然一开始这很棒，并且可能非常适合你的项目大小，但你会发现如果按“模块”将文件分组，你会更快地找到它们。

一旦您达到 6-10 个不相关的功能，您就会希望将组件文件靠近实用程序和特定于您的 UI 组件或甚至可能是您的数据模型的 TS 类型。

此外，您可能更喜欢将与特定第三方相关的所有文件放在同一个文件夹中，作为模块。（例如：Sentry、Amplitude 等）

有时候，仅仅根据文件类型进行拆分可能不够好。这时你就需要使用 modules 了。

灵活且“模块化”的文件夹结构

另一种组织事物的方法是引入模块。
模块有助于将彼此相关的代码组合在一起。它们并不能取代通用代码。

以下是我们如何将以前的文件夹结构转换为更模块化的结构：

/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

我们添加了一个新src/modules/文件夹，其中我们将与同一功能相关的所有文件分组（此处，将身份验证称为“auth”），而不是将“auth”代码拆分到各处，现在将其集中在一个文件夹中。

你可能已经注意到，唯一没有改变的是src/pages/目录。我再说一遍，目录里不能有任何非页面或 API 端点的内容。

现在所有与身份验证相关的内容都已包含在内/src/modules/auth，现在理解用于身份验证的代码变得更加容易/快捷！

但是，你肯定不想总是使用模块，对吧？有时候你写的某个实用程序并不适合放在任何模块中，你肯定想快速写点代码就完事了。

模块引入了“思维复杂性”，因为现在你可以有意识地选择文件的位置。以前做这个决定比较容易，因为按类型分组文件很容易，这是一个有实际答案的选择。将组件移动到文件hooks夹是错误的，而将其移动到文件夹components是正确的。

很容易知道你做对了（或做错了）

但是，有了模块，就没有正确/错误的答案了！这让做决定变得更加困难。有时你并不知道，一开始可能不明显（甚至可能永远都不会明显）。有时你会事后才明白过来（“哦，这其实是一个模块”）。

由于模块不是解决这个问题的通用方法，因此关键是允许两者。

该common目录应用于所有非模块的内容，而该modules目录应用于所有您认为应该是“模块”的内容。

这样，您就可以获得两全其美的效果：

• 能够快速添加代码，而不用过多考虑它应该放在哪里（common）。
• 当您觉得某个东西变得太大并且所有代码片段都应该放在一起时（从 转换为），您可以按照自己的节奏进行组织。commonmodules
• 能够在现有模块中快速找到代码并概览模块的大小。

我是Next Right Now的作者，这是一个可用于 Next.js 生产的样板，上述文件夹结构是我们自 2021 年 1 月 20 日起使用的。它是NRN 社区反馈的结果。

除了这个新的文件夹结构之外，Next Right Now 还迁移到了“模块路径别名”，它使用绝对路径而不是相对路径来导入模块。（例如：import ('@/common/hooks/useStuff')而不是import ('../../../common/hooks/useStuff').

如果您想了解有关该主题的更多信息，请阅读NRN 文件夹结构文档！