服务器端渲染如何兼容单页应用？

Question

我的问题是，我无法理解像 Next.js 这样的服务器端渲染单页面应用程序框架如何在前端接收预渲染的完整 HTML，而无需重写整个页面。例如，nextjs 网站声明如下：

默认情况下，Next.js 预渲染每个页面。这意味着 Next.js 提前为每个页面生成 HTML，而不是由客户端 JavaScript 完成这一切。预渲染可以带来更好的性能和 SEO。每个生成的 HTML 都与该页面所需的最少 JavaScript 代码相关联。当浏览器加载页面时，其 JavaScript 代码就会运行并使页面完全交互。（这个过程称为水合作用。）

我了解这如何增强 SPA 在首页加载时的响应能力。但在第一次加载之后，是什么让服务器端渲染与 SPA 兼容？我认为这是由于我无法理解的根本误解而产生的，因此我还有一些进一步的问题可能会帮助您理解它：

1. SSR SPA 是否始终以完整的预渲染 HTML 进行响应，还是仅针对首页加载进行响应？
2. 如果前者为真，那么在后续响应中，客户端如何有效地仅呈现差异而不是重写整个页面？
3. 否则，如果后者为真，那么 SSR SPA 后端如何判断何时响应第一个请求、何时响应应该是整个 HTML、与后续请求、何时大部分页面已经存在等等需要发送的是一些相对最少的信息？

我对 SSR 与 SPA 兼容的原因有什么误解？

非常感谢所有解决这个问题的人！

Answer 1

通常SSR用于页面的初始渲染，因此对于第一个问题 - 对于第一个页面加载

这是必要的，因此 SPA 将更加兼容 SEO（这也可能会带来一些性能改进，但这通常是次要目标）并且搜索引擎机器人将能够解析页面而无需 JS

SSR通常有几个重要步骤：

1. 服务器渲染
2. 将渲染数据发送到浏览器
3. 保湿。Hydration - 是一个 ReactJS（因为我们在这里讨论的是 next.js）“函数”，它将服务器渲染的 HTML 绑定到前端的 React。所以基本上将服务器渲染的 DOM 绑定到 virtualDOM

在水合步骤之后，您基本上就拥有了一个功能齐全的普通 SPA，它有自己的路由并且能够自行获取数据。

通常，BE 上有不同的端点来获取数据并呈现页面。因此，基本上 BE 上的渲染过程与 FE 上的渲染过程有些相似 - 您的应用程序后端从单独的端点获取数据，应用所有逻辑并渲染应用程序。

顺便说一句，为了确保 SSR 正常工作，有一个称为“同构代码”的原则 - 即如果您使用库来获取数据，它必须同时支持 Node.js 和浏览器 API。这就是为什么，例如，当您有 Next.js 应用程序时，您必须使用 Next.js 自己的 Router - 它只能在 FE 和 BE 上工作，与 React-router 不同，这需要一些额外的步骤来实现