ReactJS服务器端渲染与客户端渲染

我刚开始学习ReactJS,发现它给了你两种呈现页面的方式:服务器端和客户端。 但是,我不明白如何一起使用它。 是build立应用程序的两种不同的方式,还是可以一起使用?

如果我们可以一起使用,那么我们需要在服务器端和客户端复制相同的元素吗? 或者,我们可以在服务器上构build应用程序的静态部分,还是在客户端上构builddynamic部分,而无需连接到已经预渲染的服务器端?

对于给定的网站/networking应用程序,您可以使用客户端服务器端或者两者兼而有之

客户端

在这里,你完全在浏览器上运行ReactJS。 这是最简单的设置,并包含大部分示例(包括http://reactjs.org上的示例)。; 服务器呈现的初始html是一个占位符,一旦所有的脚本加载,整个UI就会在浏览器中呈现。

服务器端

把ReactJS想象成服务器端引擎(像玉石,把手等等)。 由服务器呈现的HTML包含UI,因为它应该是,你不等待任何脚本加载。 你的页面可以被search引擎索引(如果没有执行任何JavaScript)。

由于UI在服务器上呈现,您的事件处理程序都不会工作,并且没有交互性(您有一个静态页面)。

这里,初始渲染在服务器上。 因此,浏览器接收到的html具有它应该的UI。 一旦脚本被加载,虚拟DOM就会被再次渲染,以设置组件的事件处理程序。

在这里,你需要确保你重新渲染完全相同的虚拟DOM(root ReactJS组件),这些虚拟DOM与你在服务器上渲染的props是一样的。 否则,ReactJS会抱怨服务器端和客户端虚拟DOM不匹配。

由于ReactJS在重新渲染之间对虚拟DOM进行区分,因此真正的DOM不会发生变化。 只有事件处理程序绑定到真正的DOM元素。

图片来源: 沃尔玛实验室工程博客

SSR

企业社会责任

NB: SSR (服务器端渲染), CSR (客户端渲染)。

主要区别在于,对于SSR,服务器响应客户端浏览器,包括要呈现的页面的HTML。 同样值得注意的是,尽pipe使用SSR,页面渲染速度更快。 在JS文件被下载并且浏览器执行了React之前,页面将不会准备好用于用户交互。

一个缺点是SSR TTFB(第一个字节的时间)可能会稍长。 可以理解的是,因为服务器需要一些时间来创buildHTML文档,这反过来又增加了服务器响应的大小。

我真的很想知道同样的研究相当多,而你正在寻找的答案是在评论中给出,但我觉得它应该更突出,因此我正在写这篇文章(我会更新一次,我可以拿出一个更好的方式,因为我发现解决scheme的架构至less有问题)。

你需要用两种方式来编写你的组件,因此基本上把交换机放在任何地方,以确定你是在客户端还是在服务器上,然后做DB查询(或者服务器上的任何适当的)或REST调用(on客户端)。 然后,你将不得不编写生成你的数据的端点,并将其暴露给客户端,然后你就去了。

再次,高兴地了解更清洁的解决scheme。