Next.js 的阴暗面 - 应用路由

今天，我想和大家分享一下 Next.js 应用路由方面令人失望的问题。

关于SSR

我假设您了解服务器端渲染 (SSR) 的概念，并且大致了解它的工作原理。
例如，服务器返回包含标记的 HTML 页面，同时 JS 和 CSS 包也在下载，用户能够立即看到页面，而解析 JS 代码则需要一些时间。

问题_rsc​

每次在 Next.js 中切换路由时，它都会首先从服务器请求一些元信息，您可以看到诸如 之类的请求{smt}_rsc，我猜 代表 _ReactServerComponent。

服务器响应如下：

Next.js 路由器即使在需要更新 searchParams 时也会发出这些请求，例如/url?param=value，这不是一个新页面，所有操作都纯粹在客户端进行，但仍然会发出 _rsc 请求。

另一个例子是，当有一个卡片列表时，每张卡片都有一个编辑按钮Next/Link组件，并对应一个独立的编辑页面/card/{some_id}/edit。Next.js
会尝试优化性能，_rsc提前预取这些请求。结果就是，每张卡片都会收到一个请求，但用户可能根本不会点击编辑按钮。

即使你的服务器和互联网连接速度非常快，网络请求也会使用户界面变慢，并给服务器带来更大的压力。

虽然 SSR 非常适合初始页面加载，但应用加载后的导航操作要频繁得多。

讨论

关于这个问题，讨论很少：

• https://github.com/vercel/next.js/discussions/59167
• https://www.reddit.com/r/nextjs/comments/1ds5nl4/what_are_all_these_rsc_network_requests/
• https://www.reddit.com/r/reactjs/comments/13vkgl0/nextjs_app_router_is_complete_failure_what/

如何解决

对于现有项目而言，切换到类似这样的系统Remix过于困难。

如果确定是纯客户端操作，可以使用window.history带有 pushState/replaceState 的普通旧接口代替 App router。

对于queryParams/来说，可以使用一个名为state-in-url的searchParams库来简化这些操作。该库默认使用state-in-url，并且提供了一个选项来使用App Router。此外，它比NUQS简单得多，使用正确的类型解析功能即可直接使用。history

感谢阅读，如果喜欢的话，请点赞并分享。