β

React服务器端渲染实践小结

背景

为什么是React?

React今年在国内特别火,一时间虚拟DOM(Virtual DOM)等酷炫概念一下刷新了很多前端开发同学的三观,关于性能优劣的争论也在知乎上看到不少。不得不说React解决了一些前端项目开发的痛点,而我最近的一年多的工作重心,都在 兴趣部落 这样一个基于兴趣社交的web产品上,有很多感同身受的地方。 兴趣部落 这个产品从初期只有移动端的2、3个页面,发展到现在50+移动页面,加上PC版的最近上线,中间经历了从2-3人的小项目到10+人团队的大型前端项目的巨大转变。这个过程中除了人员相对业务的线性增加,代码量、维护成本也是以指数速度增长的,很快代码臃肿、难以维护与测试等问题就凸显出来。虽然内部经过一些轻量的重构优化,但开发模式还是与高度的迭代节奏很不匹配。这时候,React+Webpack的组件开发模式让我眼前一亮,暗下决心要让这样的先进开发模式推广到项目团队,好东西一定要让大家有所受益,而不仅仅是技术的尝鲜、摆设。

为什么要在服务端渲染?

除了代码维护性的问题,项目代码膨胀导致的一个问题是基础库、公共资源的变大,从而导致页面加载性能日益下降。在使用React时,也第一时间考虑到对加载性能的影响,本来页面就要等待ajax返回数据,页面会不会因为React的引入变得更慢呢?不要说React那点大小根本不是事儿,在移动网络下(包含2G啊T_T)任何资源都是很珍贵的。有没有同时提高代码维护性,又能提升页面加载速度的好事呢?答案终于回到主题,就是在服务端渲染React。这里可以一并总结该方案的好处:

  1. 利于SEO
  2. 加速首屏渲染速度
  3. 享受React组件式开发的优势:高复用、低耦合
  4. 前后端维护一套代码(代码同构)

原理

如果听到AngularJS在服务器端使用,你可能会很惊讶。但是对ReactJS,完全不必如此,因为React很好的分离了DOM的操作,使得在服务器端输出页面字符串有了可能。最新的React版本0.14.1中,已经彻底将服务端需要的源码分离出来。 react-dom/server

我们使用的核心API就是ReactDOMServer.renderToString,它只会在服务端使用,并返回组件渲染数据后的HTML字符串。而接下来要做的,就是将这个HTML片段拼接回页面模版,返回到前端浏览器进行用户侧的显示。

这里还要补充一句,React组件在服务端的生命周期方法,只会执行到componentDidMount之前的方法,因为在服务端没有组件挂到文档DOM树的概念。

核心步骤

Node端的组件加载

我们要在Node端渲染组件,首先需要加载到组件,像这样:

Crayon Syntax Highlighter v2.7.1
1
2
var React = require('react');
var someComponent = React.createFactory(require('./SomeComponent.jsx'));
[Format Time: 0.0018 seconds]

但是Node默认状况是不懂怎么解析JSX文件的,所以要在之前加上:

Crayon Syntax Highlighter v2.7.1
1
2
3
require('node-jsx').install({
extension: '.jsx'
});
[Format Time: 0.0008 seconds]

React组件渲染

加载到了React组件,等到后端的数据data也拿到后,就可以进行组件的渲染了:

Crayon Syntax Highlighter v2.7.1
1
var reactHtml = React.renderToString(someComponent(data));
[Format Time: 0.0004 seconds]

data是一个json对象,比如data={'type':'test'},这时候data会以props的形式传递给组件,类似于在jsx中这样写:

Crayon Syntax Highlighter v2.7.1
1
<SomeComponent type="test" />
[Format Time: 0.0003 seconds]

拼接返回HTML

这时候组件的HTML已经渲染完毕了,可以作为HTTP的返回体的一部分返回到浏览器了,这时候大家可以根据自己的项目框架进行操作。我们在这里使用了Koa的框架,并使用了ejs的模版,所以可以参考代码:

Crayon Syntax Highlighter v2.7.1
1
2
3
4
5
6
7
8
9
10
11
12
13
var render = require('koa-ejs');
render(this.app, {
root: path.join(__dirname, '../view'),
layout: false,
viewExt: 'ejs',
cache: true,
debug: false
});
yield this.render(templateName, {
reactOutput: reactHtml,
});
[Format Time: 0.0017 seconds]

到这里基本就完成了在服务端进行React组件的渲染,但其中还有一些小问题,我们接着继续探讨。

延伸话题

关于前后端共用代码的问题

我们的JSX文件在前端与Node端是完全复用的,而服务端用到的实际代码比浏览器需要的更少,但还是有一些差异需要注意:

前后端环境的判断方法

我个人建议通过window对象来判断,因为之前使用过moduel对象来判断,会因为webpack的打包代码导致客户端侧的运行会有问题。

Crayon Syntax Highlighter v2.7.1
1
2
var isNode = typeof window === 'undefined',
React = require('react');
[Format Time: 0.0010 seconds]

资源加载差异化

我们在进行组件化开发的模式式,样式文件也是通过require方法来引入的,而Node同样是无法默认解析样式文件的。类似的,一些浏览器环境需要的工具脚本,一定是依赖浏览器API的(BOM对象),所以也不应该在Node加载,于是就有了:

Crayon Syntax Highlighter v2.7.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if (isNode) {
// 服务端需要的资源
} else {
// 组件样式
require('./Main.less');
// 工具
var ajax = require('js/ajax.js');
...
// 前端渲染组件,服务端渲染时不需要
var SlidingBar = require('../../components/SlidingBar.jsx');
// 一些mixin也不需在Node加载
...
}
[Format Time: 0.0014 seconds]

生命周期方法注意

前面也提到了,React组件在服务端只有componentDidMount之前的方法会被执行,因此也要保证在getInitialState、render等方法中不会使用到浏览器 API,而将相应的操作放到componentDidMount中执行,如ajax。另外在使用mixin时也需要注意。

关于前后端复用代码这事儿

有必要吗?

有同学会想,既然都支持服务端渲染了,全部走后端渲染呗,还搞啥前端部分的代码。(干脆我用php也能搞定,那可是世界上最好的语言,不就是动态内容嘛)
我是这么想的,原始的纯前端渲染还是有必要的,一是开发调试方便,二是在任何情况下都有另外的选择,比如目前我们采用的方案是集群的负载均衡,一个用户访问的请求,有可能是通过html+js的页面渲染,也有可能是服务器直接吐出渲染好的页面,只是其中的权重有所不同(服务端渲染的概率会更高)。当前端或后端逻辑出现异常或服务波动,对于用户来说都不受影响。

如何复用模版?

对于页面的容器来说,纯前端渲染的容器是HTML文件,而后端则是ejs的模版文件。发布时需要对二者同时发布,并需保持内容的一致性。这里可以通过构建工具来解决,服务端需要的ejs相对html文件只是多需要一些占位变量。

后端性能相关

请求放在后端渲染,势必会多一些压力点。除了需要在接入层做到负载均衡,在缓存上也可以考虑分布式缓存等优化策略。在数据超时的情况,也需要保证页面的正常输出,而此时返回的内容其实就等同于非服务端渲染的HTML页面内容。

写在最后

在React后端渲染的范畴内,目前在国内没有找到较为系统的实践总结,同时在React研发团队的支持方面,可以看到目前还有很多优化的工作正在计划(国外有不少开发者吐槽过React在服务端的性能)。但我希望可以有更多的人来尝试这个方向,并与我们进行交流,共同进步~
欢迎感兴趣的同学进行留言,或关注我的微博 http://weibo.com/lovelovelt

作者:Web前端 腾讯AlloyTeam Blog | 愿景: 成为地球卓越的Web团队!
腾讯全端 AlloyTeam 团队 Blog
原文地址:React服务器端渲染实践小结, 感谢原作者分享。

发表评论