Question

我一直在阅读诸如this one之类的讲解服务器端呈现（SSR）的教程，这些教程提出了诸如“现在，对服务器的所有请求都返回完全呈现的HTML”之类的注释。

我的理解是babel只是将react JSX解析为原始JavaScript，然后可以将其传递给客户端并进行呈现。这个概念反映在教程本身中，这些教程都导入了某种类型的“ bundle.js”文件或其他类型的文件。但是，他们一直在讲，就像将JSX完全渲染到服务器上的HTML 中一样。，然后发送给客户端。这听起来更像是pug或ejs之类的视图引擎的行为...

这种推理上的失误阻碍了我的进步，因为我感觉自己缺少一些东西。有人可以解释吗？

Answer 1

我的理解是babel只是将react jsx解析为vanilla js，然后可以将其传递给客户端并进行渲染。

这是一种可能性，也是最常见的一种可能性。但是，JSX只是一种用于描述React元素树的语言，为了在Web应用程序中可见，仍然需要将其渲染为HTML。在某种程度上，JSX代码的翻译与服务器端渲染的问题正交。工作流可以通过以下（简化的）管道来表示：


 -----   (1)    --------------------   (2)    -----------
| JSX | -----> | React element tree | -----> | HTML tree |
 -----          --------------------          -----------

步骤（1）通常是在部署时通过将Babel集成到构建过程中来完成的。但是，步骤（2）最初可以由客户端或服务器执行，具体取决于项目的设置方式。当将Web应用程序编程为调用类似ReactDOM.render(<MyApp />, root)之类的内容时，客户端将从准系统HTML文档开始，并且需要将其扩展为DOM树。

使用SSR，我们在服务器中进行了步骤（2），因此即使在执行JavaScript代码之前，也向客户端提供了扩展的DOM树。这个过程可能类似于模板引擎，但是它所要做的只是运行React的渲染步骤（例如，参见ReactDOM.renderToString）。视图的其余逻辑和状态由客户端处理。这是通过hydrate方法实现的，该方法将必要的侦听器附加到服务器提供的组件上。

blog post提到了进行SSR的多项好处：

现在，用户无需等待JS加载并在初始请求返回响应后立即获得完全呈现的HTML。

想象一下，使用慢速3G网络的用户所获得的巨大进步。您无需等待20多个秒即可加载网站，而是几乎可以在其屏幕上立即获得内容。

[...]

现在，对服务器的所有请求都返回完全呈现的HTML。对于您的SEO部门来说是个好消息！

抓取工具现在将您的网站视为网络上的任何其他静态网站，并将您在服务器上呈现的所有内容编入索引。

因此，回顾一下，我们从SSR获得的两个主要好处是：


初始页面渲染的更快时间

完全可索引的HTML页面

React SSR工作流程中的JSX渲染在哪里发生？

1 个答案: