react native text换行_基于React+Koa实现React SSR服务端渲染

React Server-Side Rendering
其实这个概念很早之前就有了解了，出于没有应用场景原因，之前一直都只停留在了解API的层面，未曾去实践。快到周末闲来无事，自己复盘了下之前做的新商城，一直在考虑有没有更好的方案，于是React Server-Side Rendering被很自然的写到了草稿纸上，一起写上去的还有egg.js。
总结一句，接入服务端渲染有服务端渲染的好，客户端渲染有客户端渲染的更好。

这是背景。

2019.04.12更新

发现我这个react-ssr的github仓库代码和这篇文章的思维被掘金的一个博主抄到掘金社区，他那篇文章拿了高赞。他连我仓库的里前端工程代码都拿出来写到博客里，而且没有备注出处！真希望大家尊重原创性。

2019.04.01 更新

补充一个最终上线完的体验。

最终线上产品体会；相比于传统的服务端渲染，React SSR可以做到更完善的体验；相比于前后端完全分离的SPA，React SSR可以做到首屏更快的得到展示，浏览器解析渲染完dom节点既可以展示了。我的个人博客是这个方案实现的（Koa2 + React SSR + Mongdb），可以参考下。

王佳欣的小站www.shuxia123.com

----以下是原文----

问题？

为什么React既可以做browser浏览器端的渲染，又可以做server服务端，还可以做native客户端的渲染呢？

因为React将渲染工作交给了react-dom(浏览器渲染)、react-server(服务端渲染)、react-native(客户端渲染)等渲染器。而React 包只负责定义react，让我们可以使用react的特性，如：component、createElement、lazy、createContext、createRef等等在特性，这些特性任何平台都可以正常使用的，不负责具体的渲染工作。

而，各个渲染器中指定了特定的平台，实现各个平台的渲染逻辑和平台特性，如react-dom.render就可以实现dom的渲染。

所以，react就能实现多端渲染，只要在不同的端，引入不同的渲染器就可以了。

好处？

1、可以优化SEO，可以优化首屏白屏的加载时间。

2、不需要开发额外的模板

如果采用使用SSR做node渲染的前后端分离，可能要开发多套模板的，比如：加载更多的情况，就需要做一套node使用的nunjucks模板（用于渲染首屏数据渲染），和一套浏览器js使用的模板（用于加载更多时），比较难维护。

采用SSR渲染使用’ react-dom/server’ 的 renderToString对React组件进行渲染的，因此只需要开发一套组件（React 模板），避免了开发多套模板的工作。

3、单页更好做用户体验的优化，这点也很重要。

重新翻阅了React、React-Router服务端渲染的API，

ReactDOMServer – Reactreactjs.org

React Router: Declarative Routing for Reactreacttraining.com

一：总体大纲

开始动手实践前，我画了张大概流程图，捋了捋思路，我把原图贴一下，希望有些帮助。

如上图（有点丑）所示：

Server端(Koa实现)需要做3件事：

Koa-Router路由处理，服务端路由的处理。
数据处理，根据请求的信息(路径、参数等)，获取需要的数据。
渲染模板(dist/index.html)，根据模板和数据渲染内容。返回给客户端。

Client端(React实现)

构建一个模板文件(dist/index.html)，服务端渲染是会用到该模板文件。

模板内定义好要渲染的信息。

seo信息，title、keyword、description字段信息
layout信息，既服务端渲染dom内容，ReactDOM.hydrate/render是会用到该节点。
window['defaultReaderData’]信息，json格式的初始信息，供给React组件在浏览器端首次渲染时使用，确保渲染dom与服务端渲染的dom一致。

2. React-Router定义路由，保持与服务端定义的路由一致，所以采用BrowserRouter形式的路由。

3. Redux数据处理，为了使React组件首次渲染dom与服务端渲染的dom一致，所以createStore时，默认数据用window['defaultReaderData’]

4.路由切换时，路由的目标组件，完成数据获取，与组件的重新创建/更新。

二：开始动手

思路捋清楚了，然就做吧。

服务端开发

服务端依赖比较少，可以浏览器访问接口直接测试，所以从服务端开始。

以首页和详情页为例子。需要实现以下的页面路由和数据接口路由(RestFul规范)。

1、路由准备

// 页面路由

http://xxxx.com/

http://xxxx.com/detail/4840388

// 接口路由

http://xxxx.com/api/home

http://xxxx.com/api/movie/1652592

// demo文件
let router = new Router({prefix: '/'
});
router.get('/', demoControl.home);
router.get('detail/:id', demoControl.detail);// api/demo 文件
let router = new Router({prefix: '/api'
});
router.get('/home', ApiControl.fetchHome);
router.get('/movie/:id', ApiControl.fetchOneMovie);

模板渲染（{{ xxx }} 是需要通过服务端渲染的占位符）

模板文件：

<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title>{{ title }}</title><meta name="keywords" content="{{ keyword }}"><meta name="description" content="{{ description }}">
</head>
<body>{{ layout | safe }}<script type="text/javascript">window['defaultRenderData'] = {{ data | dump | safe }};</script><script type="text/javascript" src="http://localhost:8088/index.js"></script>
</body>
</html>

渲染模板：

通过React Api文档，了解到’ react-dom/server’ 的 renderToString 可以在将React组件渲染成字符串，我们可以根据它来构造layout的内容。

renderToString会触发React组件的constructor和render和componentWillMount方法，然后dom字符串。这也解释了为什么componentWillMount中setState或者获取数据会不安全。因为，如果再componentWillMount中或数据获取的话，那么服务端渲染时可能会导致数据的多次获取。原文是这样讲的。

The above code is problematic for both server rendering (where the external data won’t be used) and the upcoming async rendering mode (where the request might be initiated multiple times).

StaticRouter 的context属性设置的数据，在Client端匹配路由组件可以通过this.props.staticContext获取到，这样方便我们将数据直接输出到目标组件。

const store = createStore(model.data);
const reactDomStr = renderToString(<Provider store={ store }><StaticRouter location={ctx.request.url} context={model.data}><Layout /></StaticRouter></Provider>
);ctx.response.body = ENV.render(view, Object.assign(// layout组件节点渲染结果{ layout: reactDomStr },// seo相关model.seo || {},// 服务端渲染的数据{ data: model.data || { home: {} } })
);

数据处理：

这边不做深入介绍了。

客户端开发：

模板准备

我用webpack做的项目工程，因此只要构建一个html即可。这边需要注意的是不同环境的配置，以开发环境来说，为了在更新所以在构建模板是，模板引入资源publicPath设为http://localhost:8088/与devServer配置的端口一致。其他环境大家可以看配置文件build/cofig.js

路由准备：

<div id="app" className={className('layout')}><Switch><Route path="/" component={Home} exact /><Route path="/detail/:id" component={Detail} /></Switch>
</div>

其他的就不做深入，介绍了。可以看下git库，欢迎大家提建议。

webpack 定义依赖目录，在node环境下的解决方案

webpack依赖目录与 nodejs依赖目录

webpack中配置resolve.alias依赖目录，方便import

// build/webpack.base.config.js文件
alias: {'@scss': resolve('src/assets/scss'),'@api': resolve('src/api'),'@containers': resolve('src/containers'),'@components': resolve('src/components')
},

因此node下也需要配置一致的目录，否则会提示"@components 目录找不到"。这个可以通过 module-alias 进行配置。

// package.json 配置
"_moduleAliases": {"@scss": "src/assets/scss","@api": "src/api","@containers": "src/containers","@components": "src/components"
}

One More Thing

实践过程中，踩到的一些坑点。

node 需要支持ES6 modules，解决方案是 @babel/register
需要服务端渲染的组件，constructor和render不要写类型window、document等浏览器特有的对象。
Client端接口服务采用whatwg-fetch@2.0.4
这个案例中我没有让koa支持webpack配置，没有支持在需要服务端渲染的组件import 样式文件，用了另一种方式。
这个案例我未支持immutable.js，遇到了一些问题，还在处理。
renderToString 服务端渲染组件只会触发constructor和render和componentWillMount，不会触发其他声明周期，因此需要注意下。
别再componentWillMount里做数据获取，记住，这很重要。

源码github地址，如果刚好你有React-SSR的开发经验，欢迎讨论呀。

coocssweb/react-ssrgithub.com

大概效果如下：

目前简单的实现了，首页和详情页的功能。