Next.js——一个你可以长期使用的 React 入门套件

我几乎尝试过所有流行的 React 入门套件。2016 年，我为了学习 React 而安装的第一个 npm 包是 react- create-react-appredux-starter-kit。第一次执行完这个包后，我很快就着手创建自己的自定义 React 入门套件，但很快意识到我根本没打算维护它。之后，我又用 Gatsby、react-redux-starter-kit 等工具搭建了一些小项目，等等。

虽然我可以将 Next.js 与 Gatsby 和 Create React App 进行比较，但为了简洁起见，并展示其强大的功能，今天我选择以 Create React App (CRA) 为例。

针对CRA

我使用 create-react-app 时，最终都免不了要运行 `eject` 命令。运行之后，你会看到 webpack、babel、eslint、jest 和其他工具的各种配置，其中很多你都不确定是否真的需要。但这个过程让我有点担心哪些依赖项可以移除。一旦运行了 `eject`，你就完全得靠自己了。所以你只能选择：要么项目只有一个依赖项，create-react-app这样就能掩盖臃肿的依赖；要么就得自己承担所有被它掩盖的依赖项，并自行管理这些臃肿的依赖。

我的需求

1. 为了说明情况，我决定重新设计我的作品集网站。我希望尽快完成，最好在一周之内。花好几天时间反复调整客户端配置，力求做到“完美”，结果项目上线后却发现优化严重不足，这毫无意义。因此，使用引导程序是必要的。
2. 我想要一个与测试无关的入门工具包。Jest 很棒，而且在过去几年里取得了长足的进步，但我仍然更喜欢在 Jest 之上使用类似 的工具react-testing-library，并搭配一些用 Cypress 编写的烟雾弹式端到端测试。正因如此，我希望完全自己管理测试配置代码。
3. 我希望对选择使用的客户端库有很强的控制权，并且需要一些灵活的工具。
4. TypeScript。我爱TypeScript，还能说什么呢？虽然CRA确实支持TypeScript，但支持并不完善。你必须使用自定义模板命令初始化CRA。之后，CRA会尝试同时使用Babel和TypeScript，这会带来一些有趣的副作用，例如不支持枚举和命名空间。
5. 我不想再操心“弹出”之类的流程。我想要一个客户端入门套件，它能让我浅尝辄止地表达一些不同意见，并能根据预期进行自定义。
6. 对于我的大多数业余项目，比如我的作品集网站，完全用 Express、GraphQL 等技术编写一个独立的服务器实在是大材小用。这类项目只需要一定程度的服务器端支持就足够了，这样我就可以锦上添花地编写一些简单的轻量级 API 接口。

进入 Next.js

1. 使用 Next.js 的第一个神奇时刻，是我想要在项目中添加 TypeScript 的第二个时刻。Next.js 的理念是“无需配置”，而他们也确实做到了。在构建过程中，他们尽量不干涉你的工作。我按照简短的 TypeScript 配置指南操作，结果就像苹果产品一样，“开箱即用™”。我无需担心 webpack 在底层做了什么，也不用担心 TypeScript 的任何限制（例如枚举和命名空间在 CRA 中无法正常工作）。
2. 第二个令人惊艳之处在于 Next.js 处理客户端路由的方式。next/Link组件可以用于任何位置，并能处理所有你想要的内部链接。放置在/pages指定目录中的 React 组件会根据文件命名规则自动注册为路由。非页面组件（例如可重用、共享组件）可以放置/pages在指定目录之外的任何目录中，以避免将其暴露为路由。
3. API 层。Next.js 目录下/pages/api包含对编写自定义轻量级 Next 端点的支持。就我而言，我只需要一个极简的客户端 API，所以这非常适用。随着项目的扩展，他们还支持添加自定义中间件，遵循类似 Express/Koa 的语法，使用包含(request, response, next)参数约定的函数回调。此外，无需担心跨域请求，因为提供客户端服务的服务器也提供客户端 API 服务。Vercel 还拥有SWR包，他们建议将其与客户端 API 搭配使用。SWRstale-while-revalidate通过易于使用的 React Hooks 实现缓存失效策略，从而辅助客户端请求缓存。
4. Next 在某些方面缺乏主观意见，这反而令人耳目一新。我可以自己搭建测试套件，不必担心那些幕后运行的“神奇”测试框架会给我添麻烦。我开始添加字体库、动画库、Prettier 和 ESLint。
5. 密钥共享。Next.js 内置了密钥共享机制，这是一种相当标准的流程。在配置文件中指定的环境变量.env.local会被附加到密钥共享中process.env，并且可以在客户端和服务器端以这种方式使用。

当你需要超越自我时

Vercel 似乎明白，你最终可能想要摆脱默认设置，尝试自己的方案。这时，你无需从 Next.js 中“弹出”，而是可以通过修改 webpack 配置文件来指定一些传统的构建流程next.config.js。Vercel 的文档中包含了将默认的 CSS Modules 配置替换为 JSS 或 Sass，以及添加 PostCSS 支持等示例。

好处

我不会深入探讨 Next.js 的所有优点。但 Vercel 确实在这里加入了一大堆功能。

• 预渲染组件可以提高性能和搜索引擎优化 (SEO) 效果。
• 快速刷新感觉就像 webpack 热重载功能开始服用性能增强药物一样。
• 使用该组件进行图像服务/缓存的体验非常棒next/Image。
• Vercel 的部署平台专为与 Next.js 搭配使用而构建，并且提供极具吸引力的免费套餐。两者结合使用，又一次为我带来了“神奇体验”。
• 想了解更多信息，我推荐阅读[为什么选择 Next.js]。( https://nextjs.org/ )

注意事项和缺点

虽然我认为 Next.js 非常适合我的需求，但没有任何 npm 包是万能的。Next.js 也存在一些缺点，而且不可否认，它也存在一些比较明显的缺陷。

1. JSS.Next默认支持 CSS Modules。虽然您可以自由选择使用 CSS Modules，但使用 JSS 存在一个技术限制，即不能在服务器端组件中使用它。诸如此类的限制促使代码库倾向于使用 CSS Modules，并且用户也应该接受这种做法。最终，这种权衡对我影响不大，但对您来说可能并非如此。
2. 如果修改了TS 配置，Next.js 会自动重新生成它预期的配置。不过这倒也并非全然不好，因为标准的 TS 配置对于大多数项目来说已经相当灵活了。我当时想让编译器更严格一些，结果就遇到了问题。虽然有一些变通方法（比如使用优秀的 eslint 规则和 TS 插件），但我最终还是采用了以下方法，效果还不错：

"extends": [
    "airbnb",
    "plugin:cypress/recommended",
    "plugin:react/recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended"
  ],

TLDR；

自从开始使用 Next.js 以来，我开发业余项目的速度从未如此之快。它让我摆脱了繁琐的样板代码，能够快速地编写代码库中更有趣的部分。这个包能够做到这一点，同时又让我感觉一切尽在掌控，完全不用担心“eject”之类的流程。我彻底被它征服了，以后遇到任何新的前端项目，我都会毫不犹豫地选择 Next.js。