为什么需要服务端渲染？

1、更好的SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。（原因很简单，因为客户端渲染全部依赖于虚拟DOM，而搜索引擎爬不到虚拟DOM（主要是国内搜索引擎）
2、解决首屏白屏问题

react服务端渲染的条件

React 之所以可以做到服务端渲染 是因为ReactDOM提供了服务端渲染的API

• renderToString 把一个react 元素转换成带reactid的html字符串。
• renderToStaticMarkup 转换成不带reactid的html字符串，如果是静态文本，用这个方法会减少大批的reactid.
  这两个方法的存在 ，实际上可以把react看做是一个模板引擎。解析jsx语法变成普通的html字符串。
  我们可以调用这两个API 实现传入ReactComponent 返回对应的html字符串到客户端。浏览器端接收到这段html以后不会重新去渲染DOM树，只是去做事件绑定等操作。这样就提高了首屏加载的性能。

react服务端渲染的过程

1. 请求html
2. 服务端请求数据( 内网请求快 )
3. 服务器初始渲染（服务端性能好，较快）
4. 服务端返回已经有正确内容的页面
5. 客户端请求js/css文件
6. 等待js文件下载完成
7. 等待js加载并初始化完成
8. react-dom( 客户端 )把剩下一部分渲染完成( 内容小，渲染快 )

React/redux服务端渲染

为什么要把state(redux)从服务端传到客户端？
保证前后端数据的一致性

React 同构

node服务端

继前后端分离之后，Node出现，谷歌 V8 引擎给力支持，众前端拿着看家本领(JavaScript)开始涉足服务端，于是服务端渲染上又一步进阶，由于前后端时候的相同的语言，所以前后端在代码的共用上达到了新的高度，页面模版、node modules 都可以做成前后通用。同构的雏形，只是共用的代码还是有局限

前后同构

有了Node 后，前端便有了更多的想象空间。前端框架开始考虑兼容服务端渲染，提供更方便的 API，前后端共用一套代码的方案，让服务端渲染越来越便捷。当然，不只是 React 做了这件事，但 React 将这种思想推向高潮，同构的概念也开始广为人传。

同构实现关键因素

同构注意事项

componentDidMount() {
    // .. 判断是否为同构 
    if (identity !== UNKOWN) {
        this.setButton(identity);
    }
}  

参考文章