颁布 15 要用好他变得更难了 Next.js

前几天，Next.js 15 正式颁布了。而后我就再接再励的经过重构一个名目去感触 Next.js。

全体经常使用上去的觉得是，要用好 Next.js 的难度更高了。

这里最外围的两个要素，一方面是底层允许了 React 19，未来会成为干流的开发形式。另外一方面是 App Router 的关键性进一步被官方团队强调，经过一年多的继续预热和强推，Page Router 到 App Router 的更新曾经成为了无法逆的趋向。

实践上在这个期间节点，React 19 还没有正式颁布，他目前还只是 RC 版，然而，Next.js 的自动名目中，曾经间接经常使用 React 19 RC 了。

React 19 的开发思想和之前的版本有很大的不同。其中最关键的影响，就是在底层代码中，齐全的、彻底删除了形式。

从 React 17 开局，React 中就存在两种形式。

一种是传统的legacy形式。咱们可以暂且便捷粗犷的将其翻译为同步形式。由于该形式下的大少数关键底层函数，都是基于sync来命名。例如shceduleSyncCallback、performSyncWorkOnRoot等等。

另外一种就是Concurrent形式。也就是咱们听到很多的并发形式。然而由于常年以来，关于并发形式的思索与允许并不成熟，因此在实践的开发中，无看法的经常使用并发形式来处置实践名目疑问的团队并不算多。因此，并发形式更多的出如今技术类文章里，或许面试里。实践上要怎样用他，许多团队也还没有一个十清楚白的方向与感触。

当然，经过常年间的预热与宣传，并发形式到目前为止，曾经构成了共识，在 React 19 中，legacy形式的一切代码，都被间接删除。那么也就象征着，假设咱们要用好 React 19，就必定要对并发形式有一个十分深入的了解。

也正由于如此，许多名目要更新到 React 19 将会存在不少难度。当然，由于并发形式实践上曾经过渡了很多年，许多团队的名目自身就是间接基于 React 18 来开发，那么更新的难度会小很多。

除此之外，React 19 所倡议的开发形式，与之前的版本相比，也产生了很大的区别。

一种很关键的思绪就是：咱们要求尽或许的把 useEffect 变成一个十分小众的 hook，只会偶然经常使用一下。

这会让许多 React 开发者感遭到不顺应。因此，在我的付费小册《React 19 全解》中，我花了很大的篇幅来引见 React 19 的细节，协助大家能够极速把握这种新的开发思想。

App Router 实践上也曾经教训了一两年期间的预热，然而经过群友的反应来看，依然会有很多同窗在经常使用他的环节中觉得不顺应。

在 Next.js 15 中，App Router 变成了官方团队主推的打算。这里最外围的是要 重推 React Server Component【简称：RSC】

这就不是一个便捷的更新了，而是一次性齐全的改革。

开发者要求十清楚白的区分客户端组件与服务端组件。假设用得不好，你或许会发现你的名目里四处都是use client，这样不只不能享遭到 Next.js 给你带来的优化，反而会觉得处处遭到限度。

关于这个点，许多人会对use client的经常使用感到困惑的要素是由于，没有了解到use client他代表的含意是：边界，而不只仅是标识组件是一个客户端组件。

这里的边界指的是，服务端与客户端组件的边界。咱们只有要标识边界，那么边界之下的一切组件，都会智能变成客户端组件，而不要求咱们手动在每个组件中减少use client。

当然，这里的高低级相关，指的并不是父子结点，而是文件引入的结构。

这带来的一个强度很大的影响就是：关于经常使用者的组件正当拆分有很高的要求。这会让许多的基础经常使用者觉失掉不顺应。许多初中级开发者很难做到正当的拆分组件。

因此，他们会吐槽说，Next.js 的组件拆得太碎了，适度拆分等等。然而有的时刻这种拆分是必定的，假设咱们能够正当的把服务端逻辑与客户端逻辑处置好，关于名目的全体运转性能是十分有协助的。这是 Next.js 谋求的一个很关键的目的。

对组件的属性疑问剖析不明白的话，经常会在开发中遇到报错。由于服务端组件有十分多的 api 是不能经常使用的。假设你在编写这个组件的环节中，并没有思索该组件究竟是 server 组件，还是 client 组件，你大略率会遇到很多报错

当咱们经常使用阅读器才存在的一些行为，例如点击事情时，咱们就必定经常使用 client 组件。这要求咱们在开发阶段，就要做好动态分别，把点击事情相关的逻辑独自拆分进来从新封装一个客户端组件

这或许是很多人舒服的一个比拟关键点。由于在 App Router 中，有几个关键的 API 隐没了。他们就是

这些 API 的隐没，会让初学者很难明晰的判别进去 SSG 与 SSR 的界限在哪里。例如，当咱们想要提早失掉到页面所要求的数据时，就经常使用getStaticProps，这样，页面出现所要求的数据，就可以在构建的时刻取得

这几个 API 存在的好处就是，页面究竟是 SSG 还是 SSR，是由开发者来控制的。

然而在 App Router 中，逻辑大变。

开发者不再要求去区分我究竟要求渲染成什么 SSG 还是 SSR。

假设咱们要切换到灵活渲染内容，那么或许要求经过调整缓存战略来成功。如下图所示

这形成的结果是，或许咱们写的代码大少数都会被渲染成 SSG，而当咱们要求一些灵活生成的页面【SSR】，就进一步要求咱们对每个灵活 API 有深入的了解。

学习老本变得更高了。

然而我团体更喜欢这样的形式。由于在实践的开发中，咱们发现，假设名目中存在少量灵活渲染的内容，当访问量规模变大之后，服务端的压力会变得十分大，从而让访问速度变得更慢。因此，尽或许少的经常使用 SSR 是我在名目开发中的一个比拟大的准则。

我会尽量把与详细用户强关联的展现消息放到客户端组件中去处置。这里的前提是，经过剖析发现，与客户强关联的内容大少数状况下都没必要做 SEO。

Next.js 15 颁布之后，对三方生态库来说，是一个渺小的应战。由于许多库对 RSC 的允许并不是那么友好。因此在更新之前，大家必定要做好调研上班。评价好详细的危险与影响。

当然，新版本在开发体验上的优化是十分清楚的，无论是构建速度，还是编译速度，又或许是名目性能，都有十分清楚的优化。假设三方库的影响是可控的，那么更新到新版本所带来的收益十分大。