详解React 服务端渲染方案完美的解决方案(3)

Rendora 是我见过的接近于完美的动态渲染器，提供零配置服务器端渲染

我们到底选择哪一种服务端渲染呢？

Rendora，新的方式非常厉害，有很多优势：

• 方便迁移老的项目，前端和后端代码不需要更改。
• 可能更快的性能，资源(CPU)消耗可能更少，Golang编写的二进制文件
• 多种缓存策略
• 已经拥有 docker 容器方案

此工具，服务端渲染的页面需要缓存，缓存引发的小问题就是

通过缓存解决，性能问题和调用API两次的问题，服务端渲染，客户端展示渲染，平常调用一次API，现在调用了两次。

被缓存的页面，不能及时清理，比如网站发现用户发了不良信息，需要清理，就需要清理缓存页面了。如果想提高用户体验，浏览器端一些页面需要服务端渲染，这个时候服务端需要请求API，就会有权限问题，或者直接从缓存里面读取的HTML，到浏览器客户端，可能会有服务端和浏览器端渲染不一致的错误。

如果上面两种方式不在你的考虑范畴之内，那Rendora将是你完美的服务端渲染解决方案

总结

感觉我的轮子kkt-ssr 好像白写了一样，经过分析发现目前还有一点作用吧，至少解决了不多调用一次API，和API调用权限问题导致渲染不一致的问题。但是我更推荐Rendora的方式，这将是未来。

补充：

同构方案

这里我们采用React技术体系做同构，由于React本身的设计特点，它是以Virtual DOM的形式保存在内存中，这是服务端渲染的前提。

对于客户端，通过调用ReactDOM.render方法把Virtual DOM转换成真实DOM最后渲染到界面。

import { render } from 'react-dom'
import App from './App'

render(<App />, document.getElementById('root'))

对于服务端，通过调用ReactDOMServer.renderToString方法把Virtual DOM转换成HTML字符串返回给客户端，从而达到服务端渲染的目的。

import { renderToString } from 'react-dom/server'
import App from './App'

async function(ctx) {
  await ctx.render('index', {
    root: renderToString(<App />)
  })
}

状态管理方案

我们选择Redux来管理React组件的非私有组件状态，并配合社区中强大的中间件Devtools、Thunk、Promise等等来扩充应用。当进行服务端渲染时，创建store实例后，还必须把初始状态回传给客户端，客户端拿到初始状态后把它作为预加载状态来创建store实例，否则，客户端上生成的markup与服务端生成的markup不匹配，客户端将不得不再次加载数据，造成没必要的性能消耗。

服务端