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

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

欢迎来到 Stackoverflow :)

通常 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 自己的路由器——它只适用于 FE 和 BE，这与 react-router 不同，这需要一些额外的步骤来实现这一点