转载

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。这里可以一并总结该方案的好处：

利于SEO
加速首屏渲染速度
享受React组件式开发的优势：高复用、低耦合
前后端维护一套代码（代码同构）

原理

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

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

核心步骤

Node端的组件加载

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

varReact=require('react'); varsomeComponent＝React.createFactory(require('./SomeComponent.jsx'));

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

require('node-jsx').install({     extension:'.jsx' });

React组件渲染

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

varreactHtml=React.renderToString(someComponent(data));

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

<SomeComponenttype="test"/>

拼接返回HTML

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

varrender=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, });

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

正文到此结束