3 「武装思想」- React SSR 根本原理(1)

m0_60667406

于 2024-03-16 18:34:36 发布

阅读量851

点赞数 16

分类专栏：前端程序员文章标签： react.js javascript 前端

本文链接：https://blog.csdn.net/m0_60667406/article/details/136767354

版权

前端程序员专栏收录该内容

8 篇文章 0 订阅

订阅专栏

不过这个转换的过程不需要我们来完成，react已经帮我们完成，其本身就已提供了内置方法来支持服务端渲染。

同构

–

React 虚拟 DOM 为我们实现 SSR 提供了基础条件，但是单纯的 SSR 和传统的 SSR 没有什么区别，React中的组件也只能用作其他模板语言的代替品。。。

那么为什么还要基于React来实现SSR呢？

既然这种技术能够出现，肯定是因为有他独特的魅力和优点。

我们要明白一点，服务端渲染的核心作用。

SSR主要是直接表达出页面最基础和核心的内容这就够了。

剩下的工作就要交给浏览器了，浏览器端需要对页面的交互完成进一步的渲染、事件绑定等增强功能。

说到这里好像有点明白了，意思不就是服务端把首屏的内容直出，让用户更快的看到页面，然后后面的数据采用js来异步请求和加载。貌似不用react一样可以做到的呀。

诶，好像说的没啥毛病。确实方案不只一种，但是我们基于react来实现可以更高效，写更少的代码。因为我们可以构造同构应用。

所谓同构，就是指前后端公用一套代码，比如我们的组件可以在服务端渲染也可以在客户端渲染，但都是同一个组件。这样的方式应该是可以甩传统方式好几条街了把。

当然打造同构应用还有另外一个得天独厚的条件，双端使用同一种语言 - javascript。

SSR 部分我们使用node就能完成,所以我们才可以编写同一套代码供双端执行。

另外还有一个重要的特性也是同构的重要体现,浏览器接管页面后的进一步渲染(交互、事件)过程中，会判断已有的DOM结构和浏览器渲染出的结构是否相同，若相同，则不重复渲染，只需要绑定事件即可。

当然上面的这个特性是react提供的双端节点对比功能，也是为了最大限度的提高页面的渲染效率，尽可能的重用服务端给出的html结构。

打造同构应用

说了这么多其实本质还是react的能力，有了它的支持才能玩的转，这当然也得力于node。

说到这里，可能有同学会这样认为，既然react都为我们提供了，那我们实现起来就很方便了呀。和我们做SPA应用的时候差不多吧，只写一套代码，然后在服务端调用下react服务端渲染的相关 api ，浏览器端也不需要管，react也帮我们搞定了。

说的好像没啥毛病，但是打造同构应该不是仅仅调用几个api的事儿，如果你只是打算写一个demo玩玩，我觉得是可以的。

同构的最大优点是双端可以公用一套代码，但它是一把双刃剑，因为他还涉及到服务端，所以复杂性大大增加。

另外双端也不是完全能公用一套代码，还需要做很多差异化的处理。不只是代码层面的，还会涉及到架构和工程化。

虽然我们已经了解了react ssr的最核心的原理，但是并不能保证你能迅速的开发出这样体验的应用。

所以我们需要一个轮子，这个轮子本身已经帮我们完备了双端的差异处理，开发者只需要关心自身业务逻辑，开发中无差异化。

而这个轮子就是我们接下来要一步一步实现的React SSR应用开发骨架。

双端对比机制

上面也提到了这个概念，这里需要详细的说明一下。

为了实现服务端渲染，打造同构应用，React内部实现了相关的API，可以让我们方便的将一个组件转换为html字符串。

下面介绍几个API

import ReactDOMServer from’react-dom/server’

ReactDOMServer 类可以帮我们在服务端渲染组件 - 得到组件的 html 字符串。

下面是介绍该模块的两个方法

renderToString()

ReactDOMServer.renderToString(element)

把一个React组件渲染为原始的HTML。

我们可以用这个方法在服务端生成HTML字符串，然后将该字符串返回给浏览器端，完成页面内容的初始化，同时让搜索引擎可以抓取你的页面来达到优化SEO的目的。

另外在react 16前该方法生成的html内容的每一个DOM节点都有一个data-react-id属性，根节点会有一个data-react-checksum属性。

组件在服务端渲染后，在浏览器端还会渲染一次，来完成组件的交互等逻辑。渲染时，react在浏览器端会计算出组件的data-react-checksum属性值，如果发现和服务端计算的值一致，则不会进行客户端渲染。所以data-react-checksum属性的作用是为了完成组件的双端对比。

如果两个组件的props和DOM结构是相同的，那么计算出的该属性值就是一致的。

也可以换个角度来理解，当双端渲染的组件的props和DOM结构一致时，那么该组件只会渲染一次，客户端会采用服务端渲染的结果，仅作事件绑定等处理，这会让我们的应用有一个非常高效的初次加载体验。

ps:data-react-checksum属性值是通过Adler-32校验算法实现的。有兴趣的可以了解下此算法，这里就不详细说明了。

renderToStaticMarkup()

ReactDOMServer.renderToStaticMarkup(element)

该方法就比较轻量了，仅仅是为了将组件渲染为html字符串，不会带有data-react-checksum属性。

和上面方法的能力不同，当然使用场景也不同，如果只是单纯服务端渲染的话可以用该方法，性能肯定要比上面的方法高，因为不需要计算嘛，还能减少直出的内容体积。

性能提升

咱们上面说的都是react 16以前的，现在是什么样的呢？

从react 16开始，服务端渲染renderToString方法渲染的结果不再有data-react-*属性，当然也相应的提供了一个客户端渲染API - ReactDOM.hydrate()，从使用上来说和ReactDOM.render()没有差别。

在浏览器端渲染时，该方法会最大限度的保留服务端使用renderToString()渲染的内容，同时添加事件绑定等交互。

renderToNodeStream 和 renderToStaticNodeStream

另外 react 16 在性能上还做了改进，提供了可以将组件转换为字节流的renderToNodeStream方法。

其实使用renderToNodeStream或者renderToString对最终的渲染结果没有影响。不过renderToNodeStream的性能要好的多，可以有效缩短TTFB时间。

因为组件渲染为字符串，是一次性处理完后才开始向浏览器端返回结果。而采用流的话，可以边读边输出，可以要让页面更快的展现，缩短首屏展现时间。

那么renderToStaticNodeStream可以结合 renderToStaticMarkup理解下，作用应该很明了了。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。